Three names, three different jobs.
Most of the confusion here is caused by the shared prefix. These are not three versions of the same thing.
| What it is | What it decides | Buyer relevance | |
|---|---|---|---|
| WebGL | A graphics API. WebGL2 is the current version | How the page draws 3D | Your compatibility floor |
| WebGPU | A newer, different graphics API | How the page draws 3D, plus GPU compute | A capability upgrade with a coverage cost |
| WebXR | A device API | Whether the page can enter a headset | Whether it is immersive at all |
They combine rather than compete. A WebXR experience has to draw something, so it uses WebGL2 or WebGPU underneath. A WebGPU project may have no headset involvement whatsoever. A perfectly good browser 3D product can use WebGL2 and no WebXR at all — and many of the most commercially successful ones do.
There is a fourth name that belongs in the same conversation for a different reason: an engine. Three.js, Babylon.js, PlayCanvas and Unity are not APIs, they are the layer your supplier actually builds in. That distinction trips people up often enough that we wrote about WebXR versus Unity separately, because comparing them is comparing an API with an engine.
WebGL2 is still the floor, and that is the important sentence.
Every year someone declares WebGL finished. Every year it remains the backend that is guaranteed to work, and building on any other assumption is how a project ends up with something that runs on the developer’s machine and nowhere else.
For a buyer this has one practical consequence: if nobody on the project deliberately turned WebGPU on, what you have is a WebGL2 build. In Unity, for instance, WebGPU is an opt-in in player settings rather than an automatic default. So a supplier who says “we build modern browser 3D” has told you nothing about which path you are on. Ask directly.
The second consequence is more encouraging. For the overwhelming majority of commercial briefs — a product configurator, a walkthrough, a training scenario, a visualisation, a virtual venue — WebGL2 is not the constraint. Load time and memory are. Choosing a newer graphics API does nothing at all for either.
What WebGPU actually buys, and the one-in-seven problem.
WebGPU is not a faster WebGL. It is a modern graphics interface implemented internally against DirectX 12, Vulkan or Metal depending on the device, which is what makes new capabilities possible rather than simply making frame rates better.
The headline capability is compute shaders. A whole class of work — particles, physics and simulation, culling, sorting large Gaussian splat scenes, 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 is risk taken on for no return.
The risk is coverage. WebGPU support sits at roughly 85.6% of global usage, which sounds solved until you look at which browsers make up the rest.
| 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 skews desktop and technical. If your audience is engineers, developers or anyone inside a managed corporate environment, your real coverage is worse than the global figure suggests. Safari on macOS being only partially supported compounds it.
A global support percentage is a marketing number. The number that matters is the percentage of your audience, and it is usually lower.
The answer is not to avoid WebGPU. It is to ship both, so a browser without WebGPU falls back to WebGL2 rather than to a blank canvas. In 2026 that is the default configuration rather than a hedge. The cost is a larger build and two rendering paths to test; the alternative is silently losing a seventh of your audience and never being told.
WebXR is a door, not a renderer.
WebXR does one job: it lets a web page ask for a headset session, receive head and hand tracking, and render stereoscopically. It has no opinion about how you draw.
Its support picture is different in kind from WebGPU’s, and it matters for a reason most briefs miss.
- It works on Meta Quest and Pico headset browsers, and on Apple Vision Pro, where Safari does support it.
- It does not work in Safari on iPhone or iPad. An iPhone visitor gets the flat 3D page and no immersive mode.
- On desktop, Safari and Firefox ship it disabled.
Read that as a design instruction rather than a limitation. Most people who open your immersive link will never enter immersive mode — not because they refused, but because they are on a laptop or a phone. The flat 3D view is therefore not a fallback. It is what the majority of your audience receives, and it should be designed first and properly. Teams that treat it as a consolation prize consistently discover, after launch, that they polished the experience nine visitors in ten never saw.
This is also the cheapest possible way to de-risk an immersive project, because the flat build tells you whether the content works at all before any headset is involved. We have set out the sequence in validating an XR idea.
Four questions to put in a brief.
None of these require you to have an opinion about graphics APIs. All of them will tell you a great deal about the supplier.
1. What does a visitor see if their browser does not support your first-choice API? A good answer describes a specific fallback and how it was tested. A bad answer explains why that browser does not matter.
2. What is the download budget, and what is in it? This decides more about the outcome than any rendering choice. If nobody has a number, nobody has thought about mobile.
3. Which devices is this actually tested on, and which is the worst one? Ask for the worst, not the best. “It runs on a Quest 3” is not an answer about your audience.
4. Does this need a headset at all — and what does the flat version do? If the flat version has no clear job, the project has not been designed for the audience it will actually get.
A fifth question is worth asking about anything you intend to keep: who can change the content, and with what? That is not an API question, but it decides whether you own a product or a delivery.
Where these choices actually show up in the invoice.
Mostly, they do not — which is the useful part.
Choosing WebGL2 versus WebGPU changes engineering effort at the margins and can add a testing pass if you ship both. It does not change the cost of your 3D assets, your capture, your copy, your interface design or your integration work, and those are where the money goes. A configurator with two hundred product variants costs what it costs regardless of the graphics API, because the expense is the variants.
Where API choice does move the number is narrower and worth knowing:
- You need compute. Large splat scenes, real particle systems, on-device simulation. WebGPU plus a fallback is more work than WebGL2 alone, and it is unavoidable work.
- You have an unusually broad or conservative audience. Public sector, healthcare, education, industrial. More fallback testing, more device coverage, and it should be quoted.
- You want immersive and flat from one build. WebXR gives you that, but designing an interface that works properly on a monitor and in a headset is genuinely two design problems in one build.
Our tiers and what sits inside each of them are on the pricing page, and the cost guide covers the seven factors that move a browser 3D quote more than anything on a feature list.
What we do by default, and when we deviate.
Our default is WebGL2 with an engine that can move to WebGPU when there is a reason, an immersive session offered through WebXR where it adds something, and a flat view designed as the primary experience rather than the fallback. That combination covers the great majority of commercial briefs without a coverage argument.
We deviate in two situations. When a project needs GPU compute — large captured scenes, serious particle or simulation work — we move to WebGPU and ship the fallback alongside it. And when the requirement is genuinely beyond what any browser will render on-device, the honest answer is not a browser at all: it is remote rendering or a native application, and we say so.
If you want to judge the result rather than the argument, open one. The browser playground and Simam Immerse are live, with nothing to install. Open them on a laptop first, because that is what most of your audience will do.
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.
