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 need to test on mobile, you can use Remote Preview instead of having to export repeatedly.
In Google Chrome, it's possible to circumvent the browser security limitations and still test an exported game from disk. First close all instances of Chrome, and then start Chrome again using the following command line:
On Windows you can do this by pressing Windows + R to open the Run dialog and entering that command line. With Chrome open in this mode, you should be able to open your exported index.html file in Chrome and have it work correctly. Note the messagebox reminder might still appear (it can be ignored in this case), and other features might still not work, such as making AJAX requests to real web servers. Using this mode should not normally be necessary, but in some cases this can be useful to test an exported game quickly without having to publish it. Note if you intend to run a game locally on a computer, the NW.js export option is a better option.
Alternatively, 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.
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.
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).
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:
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.
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:
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.
noresize attributes are necessary to ensure the iframe displays at the correct size on some versions of iOS.
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!
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
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.