How to Host a Playable Web Demo of Your Game

A playable web demo is a folder of static files, and nearly any static host will serve it. Upload that folder to itch.io and you have a shareable link, a game page, a devlog and basic analytics in one step, free. Everything else in this article is about choosing a different host on purpose, or fixing the handful of engine and browser quirks that make a working build die on a real server.

The pattern keeps appearing in the community reads we run: the build finally runs, and the developer needs strangers to click something and play, without an installer, an account or a store page in the way. A web link is the cheapest test loop in games. What trips people up is the strip of work around the link: where the exported folder lives, which host sends the response headers the build expects, and what breaks when the demo meets Safari or a phone. This article covers the hosting decision, the per-engine gotchas, and the mistakes that cost an afternoon each. A disclosure before we start: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha, and what that has to do with hosting demos is near the end.

Quick answer#

The default recommendation is itch.io, and the reason is not that it is the best static host. It is that the demo ships with a page around it: cover image, description, comments, a devlog for updates, and play counts that tell you whether anyone actually clicked. A bare URL on a file host tells you nothing. Start on itch.io unless you have a specific reason not to, and read on for when the alternatives win.

What a web demo actually is#

Every engine's web export, underneath the branding, produces the same thing: a directory of static files. Godot's export is an index.html, a .js bootstrap, a .wasm binary holding the engine, a .pck pack holding your game, and a splash image. Unity, GDevelop, Construct and GameMaker differ in the details, not in the shape. The page draws the game at the maximum size the browser window allows, which is why the same folder works fullscreen on its own and embedded in an iframe on a game site.

That is why "hosting" is mostly a solved problem. A static file server with HTTPS is the entire requirement. No backend, no database, no runtime. The complications come from three places, and they recur through this article:

• Response headers. Multithreaded Godot builds and Unity's compressed builds expect specific headers from the server. Hosts that send them work; hosts that cannot, do not.
• File size. Hosts differ in whether they compress files on the fly, and a WebAssembly build left uncompressed can be four times the download.
• Browser rules. Audio cannot autoplay, saves depend on cookies and IndexedDB, and some features require HTTPS everywhere. None of these show up when you test the folder by double-clicking index.html.

Option 1: itch.io, the default#

Create a project, mark it as playable in the browser, upload the exported folder as a zip, and the page is live. The limits are documented and rarely in the way: files up to 1 GB by default, with increases granted only for a stated reason, and a cap of 1,000 files and directories for browser games, which is one reason to let the engine produce its packed format rather than a tree of loose assets.

Two things to know before you upload. First, itch.io does not compress files on the fly, so the player downloads the full bytes you upload; the Godot documentation names this explicitly, and recommends precompressing where you can and trimming what you cannot. A 400 MB uncompressed demo is a demo nobody plays. Second, command-line users should look at butler, itch's upload tool, which patches builds instead of re-uploading them, which matters when the demo is on its tenth iteration in a week.

What itch gives you beyond hosting is the reason to start here. The devlog is a built-in place to post updates that players subscribe to. Analytics count views and plays. Comments collect the feedback that a silent URL would have scattered into Discord scrolls. When the playtest article on this blog says to send testers a link with a time commitment and two questions, an itch page is that link with a shell around it.

Option 2: static hosts, when you want the URL to be yours#

GitHub Pages, Cloudflare Pages, Netlify and Vercel all serve static folders on free tiers. You lose the game page and the audience; you gain control. Choose this route when the demo needs to live on your own domain, embed cleanly in your site, or carry response headers a game platform will not send.

The published limits decide which one:

Two details make this route more than a placeholder. Cloudflare's _headers file is the cheap answer to the header problem: cross-origin isolation and MIME types become lines in a text file next to the build. And GitHub Pages compresses on the fly, which the Godot documentation calls out by name, so the same build can download markedly smaller there than on a host that serves raw bytes.

The trade is real, though. A demo on yourname.github.io has no devlog, no comment section, no play counts, and no discovery of any kind. Static hosts are for demos whose distribution you already own: a press page, a newsletter, an event booth with a QR code, an embed in your own site.

Option 3: portals, when you want the audience#

CrazyGames, Poki and Newgrounds host browser games with real traffic and pay revenue share instead of charging for hosting. The Godot documentation names Poki and CrazyGames directly as web publishers its single-threaded export targets for compatibility. GDevelop's one-click publishing goes to gd.games, its own free hosting with a game page and analytics, and GameMaker's web target is GX.games, which publishes to the mobile web in one click.

A portal is a distribution decision, not a hosting decision, and it comes with a door to get through: submissions pass a review, builds meet integration and quality requirements, and the portal's player expectations shape what the demo can be. The economics differ from a Steam launch; the audience arrives with zero context and the patience of a browser tab. Treat portals as a second home for a build you have already proven elsewhere, not as the first test.

The engine gotchas that break demos on real hosts#

These are the failure modes worth knowing before you export, because each one presents as "works on my machine":

The general rule underneath the table: the closer your export is to "one HTML file plus one packed data file", the fewer ways a host can break it. Threads, extension loading and exotic MIME expectations are where hosting friction lives.

What a Steam demo is, and why it is not this#

Steam demos are not browser games. A Steam demo is a separate application ID linked to your full game, uploaded and distributed through Steam like any build, downloaded by players through the client. It can go live on your Coming Soon page before release, it appears wherever free games appear in the store, and its first launch unlocks a one-time wishlist notification you can fire within fourteen days, which is a genuinely valuable marketing beat.

So the two demo formats serve different steps of the same funnel. The Steam demo converts store traffic into informed wishlists; our article on getting your first 100 wishlists covers that side. The web demo is the link that travels anywhere: the playtest thread, the press email, the Discord channel, the festival booth. Use both when you can, and use the web demo first, because it costs an afternoon and teaches you the same things a downloaded demo would.

Making the link do work#

Hosting is the plumbing. The value is in where the link goes:

• Playtest rounds. Small matched batches of testers, as covered in how to recruit playtesters, click a web link with zero friction, which is the whole point: no install step between the ask and the play.
• Press and creators. A journalist who must install something usually does not; a link that opens in a tab sometimes does.
• Your own channels. An embed on your site, a pinned post in your Discord, a QR code at an event, all resolve to the same folder.
• The loop after the click. This is where backend temptation starts: a leaderboard for the demo, saves that follow the player, a waitlist form. Each of those is a real problem with a no-backend answer, covered separately in adding leaderboards without a backend and cloud saves without a backend. The demo itself needs none of it to be worth hosting.

One design decision belongs to the demo, not the host: put a click or tap before the game starts. Browsers do not let pages autoplay audio, so a splash screen with a Start button is not decoration, it is the difference between a demo with sound and a demo filed under "broken".

Common mistakes#

• Hosting a threaded build where headers cannot be set. The Godot or Unity web export with multithreading enabled requires COOP and COEP headers plus HTTPS; without them the game does not run slowly, it does not run. Single-threaded export exists for exactly this reason.
• Renaming or reshuffling exported files. Web exports expect their files named as the export produced them. Upload the folder as-is, with index.html at its root, and do not "clean up" the extensionless-looking files you do not recognize.
• Shipping an uncompressed monster. On a host without on-the-fly compression, the player downloads every byte you upload. The WebAssembly binary alone compresses to about a quarter of its size with gzip when the host supports it; where it does not, the bytes are on you. Strip unused engine modules, compress textures, cut the demo to a slice.
• Forgetting that a web build is public. Everything in the folder ships to everyone who loads the page, in readable form. A community thread we read this month described a player already trying to pry a full version out of an uploaded demo. Gate content server-side or keep it out of the build; assume the folder is an open book.
• Testing only on your own machine. Localhost exempts you from HTTPS requirements, and one browser exempts you from Safari's WebGL quirks and from phones running WebAssembly at a fraction of desktop speed. Test the hosted URL, in more than one browser, before you send the link to anyone who matters.
• Leaving the demo mute. Audio autoplay restrictions mean sound needs a user gesture first. A start screen solves it and doubles as a place to set expectations for what the demo contains.
• Never writing a devlog. The iteration is the content. Tenth build of the week is exactly the material an itch devlog wants, and each entry re-notifies the people who already follow the page.

How Egmatic fits#

The hosting problem is small once, and tedious forever: export, check the headers, compress, upload, update the page, send the link, repeat for the next build. That strip of work between "it runs" and "someone is playing it" is publishing work, and publishing is the layer Egmatic is built to own: a no-code 2D editor and engine whose ship layer carries a game from scene to hosted link, rather than stopping at the canvas and handing you a folder to deploy. The AI inside it works as a craft amplifier under your direction: you decide what changes in the build, it executes, and every file stays yours, which matters most in exactly this loop, where the twentieth demo build of the week still has to ship.

We will state the stage plainly: Egmatic is pre-alpha, and we do not announce dates we cannot keep. The waitlist at egmatic.com is where the ship layer takes shape, and it is where you can tell us what your demo loop is missing, because in pre-alpha the requests arriving now are the ones that steer the build.

From scene to link, without the deploy step.

A web demo should be one decision, not an export checklist. Egmatic is a no-code 2D editor with a publishing layer that carries your build to a hosted link. Reply on the waitlist with what your demo loop is missing: requests sent during pre-alpha are the ones that steer the build.

you@example.comGet Build News

No spam. Unsubscribe anytime.

Conclusion#

Start on itch.io, because the page around the build is half the value and all of the feedback loop. Move to a static host when you need your own domain, an embed, or response headers, and remember Cloudflare's _headers file and GitHub Pages' on-the-fly gzip when you do. Treat portals as a second home for a proven build, and a Steam demo as a different instrument aimed at your store page rather than a replacement for the traveling link. Export single-threaded unless you have a reason and a host that agrees, compress before you upload, test the hosted URL in a second browser, and put one click before the sound. The whole job is one folder, one host, one link; everything after that is what the link teaches you.

Sources#

1. Godot Engine documentation — Exporting for the Web: web export as static files (index.html, .js, .wasm, .pck, splash); single-threaded export supported since Godot 4.3 and preferred for compatibility with itch.io, Poki and CrazyGames; threaded exports requiring Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp and a secure context; GitHub Pages serving gzip on the fly and itch.io not; the .wasm binary compressing to roughly a quarter of its size with gzip; WebGL 2.0 requirement; C# projects not exportable to the web from Godot 4; cookie and IndexedDB requirements for persistence; audio autoplay restrictions
2. GitHub Docs — About GitHub Pages: published sites limited to 1 GB; soft bandwidth limit of 100 GB per month; soft limit of 10 builds per hour; HTTPS on github.io domains; static files only, no server-side languages
3. Cloudflare Docs — Pages limits: 25 MiB maximum file size per asset; 20,000 files per site on the Free plan; 100 projects per account; _headers files supporting up to 100 header rules
4. Unity Manual — Deploy a Web application: gzip as the default compression format; the server needing Content-Encoding headers matching the build's compression (gzip/.gz, Brotli/.br) for native browser decompression; the Decompression Fallback option embedding a JavaScript decompressor at the cost of a larger loader and slower loading; WebAssembly streaming requiring the application/wasm MIME type
5. itch.io — community answers on upload limits, read 24 September 2026: default file size cap of 1 GB per upload, with increases granted rarely and only with justification; 1,000 files and directories per browser-game upload
6. GDevelop — publishing documentation and guides, read 24 September 2026: one-click free publishing to gd.games from the editor; manual HTML5 export (File, Export, Export as HTML5 Game) for self-hosting on any server
7. GameMaker — licensing and export documentation, read 24 September 2026: free to use for non-commercial purposes across non-console exports including the web; paid licenses required for commercial releases; the GX.games web target using a WebAssembly runner and one-click publishing
8. Construct 3 — free tier verified in our Construct 3 review against construct.net: 50 events, 2 layers, HTML5 as the only export target on the free plan
9. Steamworks Documentation — Demos: a demo as a separate App ID associated with the full game, downloaded through Steam; availability on Coming Soon pages; the one-time wishlist notification within fourteen days of the demo's first launch; demos appearing wherever free games appear; deactivation and reactivation for festivals