Putting playable Unity games directly on a website

The challenge

Clients regularly ask for a playable demo on their own website — a build a publisher or investor can open without installing anything. In practice this is where a lot of Unity projects stall.

Unity WebGL builds are large. Compressed they shrink dramatically, but the server has to announce that compression correctly or the browser will reject the file outright. On shared hosting this is usually misconfigured, and the symptom is unhelpful: a black screen, or a loading bar that stops partway with nothing in the console that points at the cause.

There is a worse version of the same problem, and it is the one that actually costs people time. Unity gives every compressed file the same .unityweb extension whether it was packed with gzip or with Brotli. Two builds made in the same editor, six months apart, can use different algorithms and look identical on disk. Configure the server for one and the other breaks — or worse, silently falls back to a JavaScript decompressor that loads several times slower while appearing to work.

The second issue is aspect ratio. A build made for a square or portrait board gets stretched or cropped when it is dropped into a page that assumes widescreen.

Our approach

We do not trust the build settings. Before a game goes up, we read the first bytes of its compressed files and identify the algorithm from the magic number — 1f 8b for gzip, anything else for Brotli. That takes a minute and removes the entire class of guesswork.

Each game then gets its own server configuration in its own folder, declaring the content type and encoding for its data, WebAssembly and framework files. The two WebGL titles on this site prove why that matters: Tic Tac Toe ships gzip, 2048 ships Brotli, and both load natively because neither is forced to share a rule with the other.

The player page treats aspect ratio as a property of the game, not of the page. A build declares itself landscape, portrait or square, and the page letterboxes it to fit — so the same page handles a widescreen racer and a square board game without either being distorted. Both current WebGL titles are square, and the layout resolves their size against the stage rather than the document, which is what stops a square game from overflowing on a wide monitor.

Uploading is handled from the admin panel: a zipped build goes in, the files are extracted to the right place, and the game appears on the site with its own page and URL. No FTP, no manual paths.

The result

Unity WebGL games run on this site with native browser decompression and no stretching, on desktop and mobile — including two builds using different compression algorithms side by side.

New builds are uploaded through the admin panel and go live immediately, each with its own shareable URL and its own page for search engines to index.

The same setup is what we deploy for client projects that need a playable browser demo.

In practice the pipeline has now absorbed five WebGL titles with mixed compression and repeated rebuilds, including a game whose hashed filenames changed between builds — the case where overwriting in place would have silently left megabytes of dead files on the server.

Every title in the library has been verified end to end rather than assumed: headers checked per file, compressed payloads confirmed to decompress to valid WebAssembly, and stage geometry measured at desktop, tablet and phone widths.