5 things I wish I knew before my first Unity WebGL export

WebGL builds are weird. Here’s how to not lose your mind exporting your Unity game for the browser.

1. Your build will be 3x bigger than you think

Unity’s WebGL output includes the entire runtime. A simple puzzle game can easily hit 20MB compressed. Use Brotli compression (the .br files) — it’s supported everywhere and cuts size by ~60%.

2. Mobile is a minefield

Unity WebGL on mobile is technically supported but practically painful. Touch input works differently, performance varies wildly, and iOS Safari has memory limits that will crash your game without warning.

My advice: build for desktop, test on mobile, and set expectations accordingly.

3. Application.Quit() does nothing

In a browser, there’s no “quitting.” Calling Application.Quit() does literally nothing in WebGL. Remove it from your UI or replace it with a “Play Again” button.

#if UNITY_WEBGL
  // Show "play again" instead of "quit"
  quitButton.gameObject.SetActive(false);
  replayButton.gameObject.SetActive(true);
#endif

4. Async operations will surprise you

File I/O, PlayerPrefs, and network calls all behave differently in WebGL. Everything is async. If you’re using PlayerPrefs.Save(), it doesn’t flush immediately — it batches writes.

Use PlayerPrefs.Save() explicitly and don’t rely on OnApplicationQuit for saving.

5. Test in the browser, not the editor

The editor lies. Things that work perfectly in Play Mode will break in the browser. Different JavaScript interop, different memory model, different rendering pipeline.

Set up a local server (python -m http.server works) and test your .html file directly. Do this early and often — not the night before your jam deadline.