Exporting Unity Games to WebGL

Step 1: Install the WebGL Build Support Module

Before you can export to WebGL, you need the build support module installed in your Unity Editor. Open Unity Hub and navigate to the Installs tab. Find your current Unity version (Unity 6 or later is recommended for the best WebGL support), click the gear icon, and select "Add Modules." Check the box next to "WebGL Build Support" and complete the installation. This downloads the Emscripten toolchain and WebGL-specific libraries that Unity needs for compilation.

If you installed Unity without the Hub, you can also add the module through the Unity Download Assistant by selecting your existing installation directory. The module is approximately 2-3 GB, so ensure you have adequate disk space. Once installed, restart the Unity Editor to make the WebGL platform available in Build Settings.

Step 2: Switch the Build Target to WebGL

Open your project in Unity and navigate to File, then Build Settings (or use the keyboard shortcut Ctrl+Shift+B on Windows, Cmd+Shift+B on macOS). In the Platform list on the left side, select "WebGL." Click the "Switch Platform" button in the bottom right corner. This triggers an asset reimport as Unity converts textures, audio, and other assets to WebGL-compatible formats. The reimport can take several minutes for larger projects.

While the platform switch is processing, Unity recalculates texture compression settings, audio encoding, and shader variants for the WebGL target. If your project was previously targeting a desktop platform, you may notice that some shaders are flagged as incompatible. Shaders using compute passes, geometry shaders, or tessellation will not compile for WebGL and need replacement with standard vertex/fragment alternatives from URP.

Step 3: Configure Player Settings

Click the "Player Settings" button in the Build Settings window to open the WebGL-specific configuration panel. Several settings here directly impact your build's size, performance, and compatibility.

Resolution and Presentation: Set the default canvas width and height. For most web games, 960x540 or 1280x720 provides a good balance. Enable "Run In Background" if your game needs to continue processing when the browser tab loses focus. Select a WebGL template, either the default "Minimal" template or a custom one that matches your hosting page's design.

Publishing Settings: Choose your compression format. Brotli produces the smallest files and is supported by all modern browsers over HTTPS. Gzip is a safe fallback if you need broader compatibility. Set "Data Caching" to enabled so returning players do not re-download unchanged assets. The "Decompression Fallback" option adds a JavaScript decompressor for browsers that cannot handle server-side compression headers, at the cost of a slightly larger loader file.

Other Settings: Set the "Managed Stripping Level" to High to remove unused .NET library code. Enable "Strip Engine Code" to remove unused engine modules. Set the initial memory size based on your game's needs, typically 32-64 MB for simple 2D games and 128-256 MB for 3D titles. If your game does not use exceptions extensively, consider setting "Enable Exceptions" to "None" for better performance, though "Explicitly Thrown Exceptions Only" is a safer default.

Step 4: Optimize Assets for Web Delivery

Asset optimization is where the most significant build size reductions happen. Start with textures, which typically account for 60-80% of a WebGL build's data file. Set maximum texture sizes appropriate to their use: UI elements rarely need more than 512x512, environment textures can often work at 1024x1024, and only hero assets should use 2048x2048. Enable texture compression (ASTC for mobile targets, DXT for desktop) and use sprite atlasing to combine multiple small textures into single draw calls.

For audio, switch music tracks to Vorbis compression at 70-80% quality and use ADPCM for short sound effects. A 3-minute music loop at full quality can be 30 MB uncompressed, while Vorbis at 70% quality reduces it to under 2 MB with minimal audible difference. Limit the number of simultaneous AudioSources to prevent CPU spikes during playback.

Review your project for unused assets. Unity includes every asset referenced by any scene in the build, even if that scene is never loaded at runtime. Remove unused scenes from the build list, delete orphaned prefabs and materials, and use the Unity Profiler's "Assets" module to identify large files that could be compressed or removed. Consider using Addressable Assets for content that is not needed at startup, allowing it to stream in on demand.

Step 5: Build and Test Locally

Return to Build Settings and click "Build And Run." Unity will prompt you for an output directory. Choose a dedicated folder (such as "WebGL_Build") and let the compilation proceed. The first WebGL build takes significantly longer than subsequent builds because Emscripten must compile the entire codebase. Incremental builds that only recompile changed scripts are much faster.

Unity's "Build And Run" option automatically starts a local web server and opens the build in your default browser. This is important because WebGL builds cannot run from local file:// URLs due to browser security restrictions on cross-origin requests. If you need to test without "Build And Run," you can use Python's built-in server (python -m http.server 8000) or Node.js (npx serve) from the build output directory.

Test on multiple browsers. Chrome, Firefox, Safari, and Edge each have different WebGL implementations with different performance characteristics and limitations. Safari on macOS and iOS is typically the most restrictive in terms of memory and WebGL feature support. Firefox often provides the best developer tools for WebGL debugging through its Canvas and Shader editors.

Step 6: Deploy to a Web Server

Upload the contents of the build output folder to your web server. The folder contains an index.html file (from your chosen template), a Build directory with the .wasm, .data, .framework.js, and .loader.js files, and optionally a TemplateData directory with CSS and loading assets.

Configure your server to serve .wasm files with the MIME type application/wasm. If you used Brotli compression, serve the .br files with Content-Encoding: br and the appropriate underlying content type. For gzip, use Content-Encoding: gzip. Most CDNs handle this automatically when configured for compressed content delivery.

For production deployment, place the build behind a CDN for faster global delivery. Set cache headers appropriately: long cache lifetimes (1 year) for versioned asset files, shorter lifetimes (1 hour to 1 day) for the HTML page and loader script. This ensures returning players load cached assets instantly while always receiving the latest game version.