Construct projects are based on HTML5, which makes them perfectly suited for web publishing. This guide includes some useful information to know when publishing Construct games online.
To publish to web, use the Web (HTML5) option when exporting. When the export finishes, you'll get a zip file which contains all the files to upload.
Exported games won't work until you upload them
Games will not work if you run them from disk. If you extract the exported zip to your computer and double-click index.html to run it, the game will start using a file:/// URL instead of a http:// or https:// URL, since the game is on disk and not on a server. For security reasons browsers have some tight limitations on what can be done in a web page from a file:/// URL, and these usually stop Construct games from working. The best workflow is to test by previewing in Construct during development, and then immediately publish the game to the web after exporting. If you run a game from disk you might see a messagebox reminding you of this ("exported games won't work until you upload them").
If you really need your game to run from the desktop, use a desktop export option instead. If you need to test on mobile, you can use Remote Preview instead of having to export repeatedly.
Local hosting
Advanced users might want to consider running a local HTTP server with a server like nginx or Caddy. These are relatively easy to set up to serve the contents of a folder on your computer at a URL like http://localhost:8080. Then you can simply copy the exported project to the server's folder, and load it in a browser. The game will work since it is running on a HTTP URL.
Uploading to the web
You will need a web server to upload your game to. If you don't have one, there are many services where you can rent a cheap static file host. The specific steps for uploading files to your server depend on your host. If you need help finding out how to do that, contact your host. The process sometimes involves tools like FTP, Remote Desktop, or a tool on the host's website. Alternatively you can export to the Scirra Arcade which hosts your game for you.
There are lots of possible services out there you could use. Two possibilities are Netlify Drop and Static.app, both of which allow you to drag and drop in some files for instant hosting.
Once uploaded, you should have a link you can share and start publicising your game! If you've designed your game with touch controls it ought to work nicely on mobile browsers as well.
It's common to make a mistake while uploading your files. If you forget to upload a file or folder, the game could break. If your game does not seem to work once uploaded, check for browser errors and hopefully there will be a useful message (e.g. "myfile.png returned 404 not found", indicating you forgot to upload myfile.png).
Setting up MIME types
For all features to work correctly, your web server should have the right MIME types set up. This is a way for associating file extensions (like .png) with a content type (like image/png). If the server does not know about some file extensions that Construct uses, it can return 404 Not Found for the file, or interpret the file incorrectly and corrupt it. For more information see the manual entry on MIME types.
Use secure hosting
Many Construct features require secure hosting to work. This means hosting your website on HTTPS (with https:// in the URL), rather than insecure HTTP (with http:// in the URL). For example offline support, fullscreen, geolocation access, camera/microphone access, and several other features all require HTTPS hosting to work correctly. It is likely in future even more features will require secure hosting.
These days any new server you set up should be secure from the start. If you have existing insecure web sites, you should start updating them to be secure.
If your website is not already secure, contact your host for support in making sure it is secure. You may need to pay to purchase a certificate. Alternatively the Let's Encrypt service allows you to get certificates free of charge.
Installable web apps
All web exports from Construct are Progressive Web Apps, or PWAs. This means on some browsers and platforms they can be installed much like an app from an app store, creating an app icon on the device, appearing like other apps without the typical browser interface elements like the address bar, and working offline (if offline support is enabled on export).
Further, some browsers allow prompting the user to to encourage them to install your web app. This can be done with the Browser object. It provides conditions to detect if an install is available. If it is, you can then use the Request install action to prompt the user to install. Note that to prevent abuse, this action is normally only allowed in a user input trigger, such as a mouse click or touch. However this allows you to do things like add a title screen menu option to install the web app.
Richer install UI
The standard install prompt is quite basic. It's possible to get a more detailed install prompt that includes screenshots of your project, so long as you provide the necessary information. This includes ensuring you enter a description for your project, and adding at least one screenshot with each of the narrow and wide form factors (see Icons & splash). For more information, including additional requirements and restrictions on screenshots, see Richer install UI on web.dev.
Domain lock
If you want to limit your game to only working on certain websites, you can simply compare the Browser.Domain expression in the Browser object. For example if you host on https://www.mywebsite.com/mygame/, the Domain expression will be www.mywebsite.com. You can make the game refuse to play if this value is not from a website you control. (Note that preview mode runs on preview.construct.net, so you should probably allow this domain too!) This makes it slightly more difficult for someone to copy your game. Note this check - any any other kind of check you implement - can still be circumvented. As with many security issues, the goal is mainly to make it more difficult to copy, rather than making it completely impossible (which is often infeasible).
Cross-domain requests
If your game loads content from another domain, this is called a cross-domain request and some security limitations can affect whether the request is allowed. For example if your game is hosted on mywebsite.com, and tries to load content from otherwebsite.com, the request might be blocked and the load may fail. This can affect AJAX requests, loading images in to objects like Sprite, playing videos, or any other time you load content from a URL.
Browsers limit requests according to their domain, scheme, and port. Together these are referred to as an origin. Requests to other origins require Cross-Origin Resource Sharing (CORS) to be set up, otherwise the browser may be blocked. Typically this involves sending the HTTP header Access-Control-Allow-Origin in the response of the server hosting the content. If this header allows the request, it can succeed. The requests can be limited to certain origins, or you can use the following header to allow requests from any server:
Access-Control-Allow-Origin: *
Don't do this for anything security sensitive (like profile information) since it allows the content to be accessed by any website on the Internet! However it's usually safe for static files that you simply want to share across domains.
Embedding
If you want to embed a game inside another web page, you can display it using an iframe element. Simply point the iframe to the web address of your game. For example:
<iframe src="https://www.mywebsite.com/mygame/" width="600" height="400" scrolling="no" noresize="noresize" />
This will create a fixed size iframe (600x400) inside of which the game will appear. By default the game will automatically scale to fill whatever size the iframe is set to. However if it's a fixed size game, make sure the width and height attributes of the iframe tag match the viewport size of the game.
The scrolling and noresize attributes are necessary to ensure the iframe displays at the correct size on some versions of iOS.
Allowing fullscreen
It's still possible for games inside iframes to switch in to fullscreen mode, where it takes up the entire display. To support this, your game must not be fixed size (Fullscreen mode must not be Off). Then use the Browser object's Request fullscreen action in your game.
Finally, you must add the allowfullscreen attribute to the iframe tag like this:
<iframe src="https://www.mywebsite.com/mygame/" allowfullscreen="true" width="600" height="400" scrolling="no" noresize="noresize" />
With all that in place, your iframed game should now be able to "break out" in to full screen mode!
Sandboxing
If you run a games arcade or otherwise want to ensure that games are isolated from the parent page, the most important point is to run the games on a different origin to the parent page. For example if the parent page is on https://www.myarcadesite.com, the iframe should point to games hosted on another origin like https://games.myarcadesite.com. The browser's same-origin security policy will prevent games being able to access any storage or content on the domain www.myarcadesite.com.
For further isolation, you can use the sandbox attribute of the iframe tag. This allows for further locking down of capabilities like opening popups, navigating the top frame, and so on. For more information see the iframe tag on MDN. At a minimum the sandbox attribute must contain allow-scripts for the game's JavaScript to run. If the game is on a different origin to the parent page, you can also use allow-same-origin.
Controlling framing
You may wish to limit which websites are allowed to display your game in an iframe. Alternatively you may wish to block the ability to display your game in an iframe at all, ensuring it can only be played when directly visiting its URL.
In modern browsers, you can control this by sending a Content-Security-Policy HTTP header with a frame-ancestors directive. For example you can set this to 'none' to block framing completely, or specify an origin to allow only that page to display the content in a frame.
For older browsers you can achieve similar results with the X-Frame-Options HTTP header.