One is an API. The other is an engine. That is the whole confusion.
The WebXR Device API is a browser feature. It hands your code a headset’s pose, its input sources and a session to render into, and it defines reference spaces so that “where is the floor” has an answer. It draws nothing. It has no editor, no asset pipeline, no physics and no opinion about your content.
Unity is an engine: an editor, an asset pipeline, a physics system, an animation system, and a runtime that ships to a target platform. It is a way of making the thing that WebXR then presents.
So “WebXR vs Unity” only resolves once you rewrite it as the question people are actually asking: for a browser-delivered XR experience, do I build it in Unity and export to WebXR, or build it natively on the web stack? The genuine alternatives to Unity here are three.js, Babylon.js, PlayCanvas, A-Frame, and now Meta’s Immersive Web SDK.
The confusion is expensive because of when it gets resolved. Teams choose Unity for reasons that are entirely about the editor — the scene view, the inspector, the asset store, the people they already employ — and only discover months later that the WebXR half of the stack is not Unity’s, and never was.
What Unity officially supports on the web, and what it does not.
Unity’s XR support pages enumerate the XR platforms it provides plug-ins for: Android and iOS AR, HoloLens, Meta Quest, PlayStation VR, Apple Vision Pro. The Web platform is not among them. That is not an oversight in the documentation; it is the situation.
WebXR in Unity means WebXR Export, a pair of community-maintained packages — WebXR Export and WebXR Interactions — that bridge the WebXR JavaScript API into a Unity Web build. The original was a Mozilla Reality project, now marked inactive; the maintained line is De-Panther’s, and it is real, current work supporting Unity 2020.3.11 through Unity 6.
What you get, and what you do not:
| Supported | Not there, or conditional |
|---|---|
| Immersive VR and AR sessions | AR Foundation — listed as the next goal, not shipped |
| Hand tracking, via Unity’s XR Hands package | Hit test is viewer space only, and not through AR Foundation |
| WebXR Input Profiles for the XR Interaction Toolkit | Built-in Render Pipeline, dropped at version 0.20.0 |
| Unity XR SDK integration, from 0.20.0 | Mobile, which the project itself says “may not work” |
| A WebXR polyfill fallback for unsupported devices | — |
Three of those decide projects rather than annoy them.
The render pipeline one is a hard gate. Version 0.20.0 dropped Built-in Render Pipeline support, so the current package means URP. If your Unity project is on Built-in — and a great many older ones are — a WebXR export is not a build setting, it is a rendering migration first.
Mobile is not the escape hatch you were hoping for. The package’s own documentation says mobile support is limited and may not work, mirroring Unity’s WebGL constraints. If the pitch for browser XR was “everyone has a phone”, check that assumption early rather than late.
Someone who is not Unity maintains your XR layer. That is not a criticism of the package, which is good and has genuine Unity XR SDK integration. It is a risk to price deliberately, in a way you would not have to for a Quest build.
The reach numbers, and the convergence that is not scheduled.
WebXR support sits at roughly 75.5% of global browser usage, and the more useful detail is that it is marked partial in every browser that has it at all.
| Browser | WebXR Device API |
|---|---|
| Chrome / Edge | Partial, from 79 |
| Chrome for Android | Partial, from 151 |
| Samsung Internet | Partial, from 12 |
| Opera / Opera Mobile | Partial, from 66 / 80 |
| Safari, macOS | Disabled by default |
| Firefox | Disabled by default |
| Safari on iOS | Not supported |
Read the last row twice. An iPhone in Safari — which is most of the mobile web in the UK and the US — cannot enter an immersive session. Whatever you build, the non-XR view of it is the majority experience, not a fallback for edge cases, and it deserves to be designed rather than degraded into.
Set that against the other two numbers a browser 3D project depends on. WebGL2 is effectively universal and is the floor Unity Web builds sit on. WebGPU is at about 85.6%. WebXR is the narrowest of the three, so even a project whose 3D runs everywhere will find that the headset session reaches the smallest slice of its audience.
The immersive session is the smallest part of your audience. Design the flat view first and you will be designing for most of the people who arrive.
The natural next thought is that this converges — that Safari and Firefox come along and the problem dissolves. It is worth knowing that this is not currently scheduled work. The WebXR API was proposed as an Interop 2026 focus area and was not selected. The twenty areas the browser vendors did agree on include anchor positioning, view transitions, scroll-driven animations, WebRTC, WebTransport and IndexedDB; the four investigation efforts are accessibility testing, JPEG XL, mobile testing and WebVTT. WebXR is in none of them.
That does not mean nothing will improve. It means no plan should have a second year that depends on Safari.
The comparison that actually decides it.
With the framing corrected, here is the real choice, on the axes that change budgets rather than the ones that win arguments.
| Unity + WebXR Export | Web-native (three.js, Babylon, PlayCanvas, IWSDK) | |
|---|---|---|
| What ships to the browser | The engine runtime as WebAssembly plus a JavaScript framework file, whether or not the scene needs them, then your data file | A JavaScript library, then your assets |
| Cold start | Runtime download and initialisation before anything renders | Effectively page load, then progressive asset loading |
| Who maintains the XR layer | A community package, not Unity | The engine itself, plus Meta’s SDK |
| Render pipeline constraint | URP, since 0.20.0 dropped Built-in | None imposed |
| Team you need | Unity and C# | JavaScript or TypeScript, and web tooling |
| Reusing existing content | Direct, if the project is already Unity and already URP | Assets port; scenes, scripts and UI do not |
| Physics, animation, authoring tools | Mature, deep, editor-driven | Improving fast, but assembled rather than given |
| Iteration loop | Rebuild the Web player | Hot reload, browser devtools, the normal web loop |
| Mobile browsers | Limited, per the package’s own docs | The platform’s home ground |
| Embedding in an existing web product | A canvas the page hosts and talks to across a boundary | Part of the application |
The pattern is consistent. Unity wins on authoring: the tools for making complex interactive content are better, and if you have them already, throwing them away is an expensive way to save on download size. The web stack wins on delivery: what arrives, how fast, how it is embedded, and how quickly you can change it.
Which of those a project is judged on is usually obvious once someone asks. A training simulation with real physics and forty procedures is an authoring problem. A product page that lets you step inside the thing is a delivery problem.
Meta built its WebXR framework on three.js, and that is the strongest signal in the room.
In 2026 Meta shipped the Immersive Web SDK, and the interesting part is not the feature list but the foundation: it is built on three.js, paired with an entity component system, and it provides physics, spatial audio, grab interactions and scene understanding out of the box. There is an @iwsdk/xr-input package specifically so it can be dropped into existing three.js projects, a single create command to start one, and tooling aimed at AI coding assistants.
The company with the largest commercial interest in WebXR succeeding built its developer story on the web stack rather than on a Unity exporter. That does not make Unity the wrong answer for your project. It does tell you where the platform investment is going, and which stack will have the most current examples, the most recent answers and the most active maintenance when you go looking for help at 11pm.
It also quietly settles a question people ask about longevity. The web-native route now has a first-party framework behind it from the dominant headset vendor. The Unity route has a well-maintained community package. Both are viable; they are not the same kind of bet.
What actually changes when a Unity project becomes a WebXR one.
We have done this conversion, and the honest summary is that it is not a port. It is a rebuild of everything above the assets.
What survives: meshes, textures, materials in principle, animation clips, audio, and the design. The art does not need remaking, which is usually the majority of the money already spent.
What does not: MonoBehaviours, prefabs, the scene graph as Unity structured it, the input system, world-space UI canvases, and the physics setup. These are re-authored against the new runtime, not translated.
The two things that surprise teams are UI and budget. World-space canvases full of Unity UI components have no equivalent; spatial UI on the web is either DOM overlaid on the session or geometry you build, and the decision affects accessibility, localisation and how much of it can be changed later without a rebuild. And the content budget shifts, because a different runtime with a different memory profile is now carrying the scene — numbers tuned for a Unity Web build are not automatically right on the other side.
None of this is an argument against migrating. It is an argument for scoping the migration as a build rather than an export, which is where the estimates go wrong.
How to choose, in order.
- Ask what the project is judged on. Reach, load time and embedding point at the web stack. Authoring depth, physics and an existing Unity codebase point at Unity.
- Check your render pipeline before anything else. A Built-in Render Pipeline project is not one setting away from WebXR Export; it is a URP migration away from it.
- Design the non-XR view first. Most of your audience will never enter an immersive session, because Safari and Firefox will not let them. That view is the product for most visitors.
- Decide who owns the XR layer, explicitly. If the answer is a community package, say so in the risk register rather than discovering it at handover.
- Do not plan around Safari. WebXR was proposed for Interop 2026 and not selected. Treat any improvement as upside.
- If you are starting from nothing and targeting Quest, start on the web stack. That is where the platform holder’s own tooling now is.
The question “WebXR or Unity” has no answer. The question “is this project mostly an authoring problem or mostly a delivery problem” usually answers itself in one sentence, and the technology follows from it.
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.
