The honest answer: possible, not official.
Look at Unity’s own XR support pages and you will find plug-ins for Android and iOS AR, HoloLens, Meta Quest, PlayStation VR and Apple Vision Pro. The Web platform is not there. That is not a documentation oversight; Unity does not ship WebXR support.
What exists instead is WebXR Export, a pair of community-maintained packages — WebXR Export and WebXR Interactions. The lineage matters: the original was a Mozilla Reality project, now marked inactive, and the maintained line is De-Panther’s. It is real, current work, it supports Unity 2020.3 through Unity 6, and since version 0.20.0 it integrates properly with the Unity XR SDK rather than bolting on beside it.
So the position is: this works, people ship with it, and the XR layer of your project is maintained by someone who is not Unity. That is a risk to write down deliberately rather than discover at handover. It is not a reason to avoid the route, but it should be a conscious decision rather than an assumption.
What you need before you start.
Three checks, and the second one ends the conversation for a lot of existing projects.
- Unity version. The package supports 2020.3.11f1 and up, 2021.1.4f1 and up, 2022.1 and up, 2023.1 and up, and 6000.0.23f1 and up. A current Unity 6 project is fine.
- Universal Render Pipeline. Version 0.20.0 dropped support for the Built-in Render Pipeline. If your project is on Built-in — and plenty of older ones are — this is not a build setting away, it is a rendering migration away. Budget for that before anything else.
- Realistic target devices. The project’s own documentation says mobile support is limited and may not work, tracking Unity’s WebGL mobile constraints. If your plan depends on phones, verify that early rather than late.
Worth knowing while you are here: WebGPU is available in Unity 6.3 but still marked experimental, and Unity does not enable it automatically the way it does WebGL2. Whatever you build here is a WebGL2 build unless someone deliberately changed it.
The seven steps, in order.
This is the whole setup. Do it in this order; several of the steps depend on the one before.
- Create the project and switch platform to WebGL. Do this first, because the later settings only appear once the platform is Web.
- Install the two packages from OpenUPM — WebXR Export and WebXR Interactions. OpenUPM is the recommended route; a direct git import also works, but the repository uses symlinks, so if you clone it locally enable them first.
git config core.symlinks true- Copy the WebGL templates. Window → WebXR → Copy WebGLTemplates. This puts the templates into your Assets folder where the Player settings can see them.
- Register the XR provider. Project Settings → XR Plug-in Management, and select WebXR Export as the plug-in provider. This is the step that makes Unity’s XR subsystem talk to the browser API rather than to a device SDK.
- Set the WebGL template. Project Settings → Player → Resolution and Presentation, and set WebGL Template to WebXR. The template is what actually requests the immersive session from the browser, so a default template gives you a 3D page with no way into the headset.
- Import the sample scene. Window → Package Manager → WebXR Interactions → Sample Scene → Import into Project. Build this before you build your own project. It tells you whether the pipeline works, separately from whether your content works.
- Build, and host it over HTTPS. See the next section, because this is where the afternoon goes.
The trap: Unity’s own Build And Run cannot work.
WebXR requires a secure context. HTTPS, or a localhost URL. Nothing else, ever, by design.
Unity’s Build And Run starts a local HTTP server. So the page loads, the scene renders, everything looks correct — and the browser silently declines to offer an immersive session. There is no error dialog explaining this. You get a working 3D page and a missing button, which is exactly the kind of failure that costs hours because it looks like your setup is wrong rather than your transport.
A working 3D page with no way into the headset almost always means HTTP, not a broken configuration.
The fix is to serve the build from an HTTPS host, or from localhost specifically. In practice that means putting a TLS certificate on your local dev server, tunnelling it, or pushing to a staging host for every device test. Set that up before you need it, because you will need it constantly — and it applies to testing on the headset over your network too, since the headset reaching your machine by IP address is not a secure context.
When this is the right route, and when it is not.
Having done the setup, the harder question is whether you should have.
| Unity plus WebXR Export earns it when | Reach for the web stack instead when |
|---|---|
| You already have a Unity project, on URP, with content worth keeping | You are starting from nothing |
| The team is Unity and C#, and retraining is not on the table | The team is web, or the 3D has to live inside an existing web application |
| You need Unity’s physics, animation systems or editor tooling | Download size and cold start are what the project will be judged on |
| The asset pipeline already exists and works | You want the normal web iteration loop rather than a rebuild each time |
The structural difference does not go away with tuning. A Unity Web build ships the engine runtime as WebAssembly plus a JavaScript framework file, whether or not the scene needs them, and only then your data. A web-native project ships a library and your assets. That gap is the price of the editor and the ecosystem, and for an existing Unity project it is frequently worth paying.
Best practices for a Unity WebXR build.
Most of what goes wrong is not XR-specific. It is Unity-on-the-web, which has its own discipline.
Build the sample first, always. Confirm the pipeline works before adding a single thing of your own. When something breaks later, you will know it was your change.
Set the download budget before the art is approved. The engine runtime is a fixed cost you cannot optimise away, so everything else has to fit in what remains. Decide the number commercially — how long will this audience wait — and hold the content to it.
Use Brotli, and check your host serves it over HTTPS. It is Unity’s recommended compression for the web, and the real benefit is that the browser decompresses natively during the download rather than in JavaScript afterwards. Chrome and Firefox only accept it natively over HTTPS, which you need anyway.
Treat memory as the failure mode. A browser 3D application that runs out of memory does not slow down, it stops. Texture resolution and scene complexity are memory decisions before they are art decisions.
Test on the actual headset browser. The Meta Quest browser is the most complete WebXR implementation available, and it is not the same as Chrome on your desktop. Frame rate, memory headroom and input all behave differently.
Keep the non-immersive view working. Most people who open the link will never enter a session, because Safari and Firefox will not let them. The page they get should be a designed experience, not a scene with a missing button.
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.
