Unity 6.6 takes WebGPU out of experimental, and leaves it switched off
Unity released Unity 6.6 on September 1. It's a "Supported" release, meaning it gets the same stability commitment as an LTS until 6.7 arrives, and it's the last stop in the Unity 6 line before that LTS. The headline for anyone who ships to a browser is one sentence from the Web Graphics team's post a week earlier: "as of Unity 6000.6, the WebGPU graphics API is no longer experimental, it is now a fully supported feature."
Unity has been running WebGPU as an experimental backend since 6.1 in early 2025. We covered that at the time and have tracked the browser side since, from Safari shipping WebGPU to all major browsers landing it. The engine side is now caught up.
Unity's own tour of what's new in 6.6
What WebGPU turns on
The reason WebGPU matters in Unity specifically is compute shaders. WebGL 2 never had them, so every Unity feature that leans on GPU compute was simply absent from web builds. With WebGPU selected, web builds get GPU Resident Drawer and GPU occlusion culling, Spatial-Temporal Post-Processing upscaling, VFX Graph with GPU-simulated particles, Adaptive Probe Volumes, and compute skinning. Unity's demo scenes for the post were Fantasy Kingdom, a dense stylized town, and a spaceship interior full of VFX Graph particles, both running in a browser.
VFX Graph particles are GPU-simulated, which is why they were never available on WebGL 2. Image: Unity.
There's also a lighter compatibility mode for hardware that reports WebGPU but can't handle the full feature set, so the same build reaches more devices without the developer doing anything.
What Unity deliberately didn't do
WebGPU is not enabled by default. WebGL 2 stays the default graphics API for web builds. To use WebGPU you open the Web player settings, uncheck automatic graphics API selection, and add WebGPU to the list. Unity tries the APIs in priority order at runtime and falls back to the next one when the first isn't available.
WebGPU has to be added to the Graphics APIs list by hand. Image: Unity.
Two caveats in the post are the kind that cost people a day if they miss them. First, browsers only expose WebGPU in a secure context, so a build served from a local file or a plain HTTP host silently drops to WebGL 2 and you'll wonder why your compute features vanished. Second, Unity's own words: "not all devices reporting WebGPU support deliver consistent experiences." That's why 6.6 adds Graphics Device Filtering, a set of rules that force the fallback for specific browsers, GPUs, or drivers you've found to be trouble.
The rest of the web story in 6.6 is about size and memory. WebAssembly64 lets a browser build address up to 16 GB of memory instead of the old 4 GB ceiling, in Chrome and Edge 128 or later and Firefox 129 or later. Progressive Asset Loading delivers assets per scene rather than as one upfront download, so a player starts on the first scene while the rest streams in. Both address the two reasons Unity web games have historically been a hard sell: they were big and they ran out of memory.
The rest of the release
Outside the browser, Fast Enter Play Mode is now the default for new projects, reloading the scene without a domain reload. Unity frames this as preparation for Unity 7's move to CoreCLR. Dictionaries serialize natively in the Inspector at last. A new Build Analysis window tracks build history and metrics, and Content Directories organize local content with Addressables integration and DirectStorage support on Windows and Xbox. Unity's example for the shader work is a build that dropped from 1 hour 46 minutes to 32 minutes after converting keyword variants to dynamic branches.
Where this leaves web games
We build on three.js and WebGPU directly, so Unity graduating its backend isn't a competitive threat so much as a confirmation. Browser GPU compute is now a supported path in the engine with the largest install base, which means more games will ship expecting it, more players will hit the compatibility edge cases, and browser vendors will feel more pressure to close them. We wrote up where WebGPU and WebGL stand against each other for games and the engine choices for the web, and the advice in both holds: ship with WebGPU on and a WebGL 2 fallback, test on real low-end hardware, and treat "the browser says it supports it" as the start of the question.
Unity leaving WebGPU off by default is the right call for a supported release, and it's also a tell. The API is ready. The device population isn't uniform yet, and the engine that has to run on all of it knows that better than anyone.