WebGL2 is still the floor, and that is the important sentence.
Every year someone declares WebGL finished. Every year Unity ships a web player whose default, guaranteed-to-work graphics backend is WebGL2. In 2026 that is still true, and building on any other assumption is how projects end up with a demo that runs on the developer’s machine and nowhere else.
Unity’s own compatibility list is short and worth reading literally. On desktop it names Chrome, Firefox, Safari on macOS and Edge. On mobile it names Safari on iOS 15 and newer, and Chrome 58 and newer on Android. The stated requirements are that the browser is WebGL2 capable, 64-bit, and supports WebAssembly. Safari before 15 has no WebGL2 at all.
The detail people miss: Unity does not enable WebGPU automatically the way it does WebGL2. It is an opt-in in Player settings. So unless someone on your team deliberately turned it on, whatever you shipped this year is a WebGL2 build, and its performance ceiling is a WebGL2 ceiling.
What WebGPU actually buys you, and what it still cannot do.
WebGPU is not a faster WebGL. It is a different, modern graphics interface implemented internally against DirectX 12, Vulkan or Metal depending on the device. That is what makes the new capabilities possible rather than just the frame rate better.
In Unity, the honest version of the trade is this:
| WebGPU unlocks | WebGPU still does not support |
|---|---|
| Compute shaders | Async compute |
| Indirect rendering | Dynamic resolution (camera-based render target scaling) |
| GPU skinning | Cubemap arrays |
| VFX Graph | — |
Compute shaders are the headline, and for good reason: a whole class of work — particles, simulation, culling, splat sorting, anything data-parallel — stops being a CPU problem. If your project needs any of that, WebGPU is the reason to move. If it does not, WebGPU in 2026 is risk you are taking on for no return.
The dynamic resolution gap deserves a flag of its own. Camera-based render target scaling is one of the most reliable tools for holding a frame rate on a weak GPU, and losing it on the exact platform with the widest hardware spread is an awkward trade.
WebGPU is worth adopting when you need compute. It is not worth adopting because it is newer.
The browser numbers say ship both.
WebGPU support now sits at roughly 85.6% of global usage. That sounds like a solved problem until you look at which browsers make up the remainder.
| Browser | WebGPU status |
|---|---|
| Chrome / Edge | Supported from 113 |
| Chrome for Android | Supported from 151 |
| Safari on iOS | Supported from 26.0 |
| Safari on macOS | Partial from 26.0 |
| Firefox | Disabled by default |
So around one visit in seven cannot run a WebGPU-only build — and the largest single block of that is Firefox, which is disproportionately desktop and disproportionately technical. If your audience is developers, engineers or anyone in a managed corporate environment, your real-world WebGPU coverage is worse than the global figure suggests. Safari on macOS being only partially supported compounds it.
Unity’s answer is the right one: you can keep both APIs available in a single build, so a browser without WebGPU falls back to WebGL2 instead of to a blank canvas. In 2026 that is not a hedge, it is the default configuration. The cost is a larger build and two rendering paths to test; the alternative is silently losing a seventh of your audience.
The real 2026 change is mobile, and almost nobody noticed.
The WebGPU conversation absorbs all the attention, but the change that actually moves projects is quieter: mobile browsers are now an officially supported Unity Web target rather than something you attempted and hoped for. Safari supporting WebGL2 is what made iOS viable at all, and Unity 6 turned that into stated support alongside Android.
Read the caveat, though. Unity’s guidance is high-end devices from roughly the last two or three years, and results vary with content. “Officially supported” means Unity will treat a failure as a bug rather than as you misusing the platform. It does not mean a mid-range Android from 2021 will run your scene.
Practically this changes who you can reach without an install: a link in an email, a QR code at an event, a page in a client’s own site. That is a commercial change more than a technical one, and it is worth more to most projects than compute shaders are.
What still decides whether it works: bytes, then memory.
After a decade of Unity web builds, the two things that kill projects have not changed, and neither is a graphics API.
Download size. Brotli is Unity 6’s recommended compression and produces meaningfully smaller files than gzip. The part worth understanding is why it helps twice: the browser decompresses natively while it downloads, which avoids the extra startup delay of decompressing in JavaScript. The cost is real but bounded — Brotli is slow to compress, so release builds take longer, and Chrome and Firefox only accept it natively over HTTPS. Configure your host properly or you get none of the benefit.
Memory. Browser 3D does not degrade gracefully when it runs out; it dies. Every decision about texture resolution, avatar counts and scene complexity is a memory decision first and an art decision second, and the ceiling on a mid-range phone is far below what your workstation suggests.
Both are design constraints, not optimisation tasks for the end of the project. Teams that treat them as a final pass ship late and cut the wrong things.
What we would actually do on a browser build in 2026.
- Ship WebGL2 and WebGPU in one build. WebGL2 as the guaranteed floor, WebGPU as the upgrade for the browsers that have it. Not one or the other.
- Only chase WebGPU if you need compute. Particles, simulation, culling, splat sorting, VFX Graph, GPU skinning. If your project is a configurator or a walkthrough, WebGL2 is not holding you back.
- Set a download budget before the art is signed off. The number is commercial, not technical: how long will this audience wait? Everything else follows from it.
- Test on a mid-range phone from three years ago. Not the newest device in the office. That device is your actual minimum spec whether you chose it or not.
- Check your host serves Brotli over HTTPS. It is the cheapest performance win available and it is routinely misconfigured.
None of this is exciting, which is rather the point. Browser 3D in 2026 is a mature platform with a known set of constraints. The projects that go wrong are almost never the ones that picked the wrong graphics API.
What this means for a buyer.
Start with the business decision, audience, and evidence the project must produce. Simam Digital can turn that into a focused discovery, prototype, MVP, or production roadmap across AI applications, SaaS platforms, digital twins, real-time 3D, XR, and interactive systems.
