The one-sentence version
WebXR is the part of a web browser that can talk to a headset. That is genuinely all it is. When a page uses it, the browser hands over the headset’s position, the controllers or the user’s hands, and a view to draw into — and the page renders into the headset instead of into a window.
It is not a product, not a company, and not a Meta thing. It is a published web standard, in the same way that playing video inside a web page is a standard. Nobody licenses it and nobody owns it.
Everything people find interesting about WebXR is a consequence of that one arrangement. Because it is a web page, it has a URL. Because it has a URL, you can send it to someone.
What actually changes is distribution, not graphics
The usual pitch for immersive technology is about how it looks. The genuinely valuable difference here is about how it reaches people.
- No app store. No submission, no review queue, no waiting a week to fix a typo, no store rules about what your experience is allowed to contain.
- No install. The person clicks a link and is inside it. There is no download screen where you lose half your audience.
- It updates on reload. Change something at four o’clock and everyone has the new version at five past. There is no old version still installed on somebody’s device.
- One build reaches several devices. The same link runs on a Meta Quest and on an Apple Vision Pro, and opens as a normal interactive 3D page on a laptop or phone.
- It behaves like the rest of your website. It can sit behind your login, live on your own domain, and be measured with the analytics you already use.
The point that gets underestimated: the person you most want to reach is usually the person who will not install an app for you. A prospect, a journalist, an investor, a customer’s procurement team, a delegate at a stand. For that audience the install step is not a small friction, it is the end of the conversation.
What it is not
Worth saying plainly, because the category has been oversold before.
It is not a replacement for a native headset game. If you are building something with demanding physics that people will play for hours, or that needs deep access to device hardware, a native build is still the right answer.
It is not supported everywhere. The immersive session works in Chrome and Edge, the Meta Quest browser, and Safari on Apple Vision Pro. Safari on the desktop and Firefox both ship it switched off by default, and Safari on iPhone and iPad does not support it at all. So for most visitors the flat, non-headset view is the experience — and that has to be designed properly, not left as a fallback.
It is not “the metaverse”. It is a delivery mechanism. What you deliver with it is a separate decision, and most of the good uses are unglamorous.
It is not free of engineering. Because it downloads when someone opens it, how much it weighs is a commercial decision rather than a technical footnote — and browser 3D does not slow down gracefully when it runs out of memory, it stops. Both are design constraints from day one, not tuning at the end.
When a link beats an app
Ignore the technology for a moment. The question is whether your situation rewards being reachable or rewards being maximal.
| A link is probably right when | A native app is probably right when |
|---|---|
| The audience is one-off — an event, a pitch, press, investors | The same people use it repeatedly, for hours |
| The content changes often | The content is fixed and ships once |
| Devices are corporate or managed, where installing is a procurement task | You control the devices and can deploy to them |
| It needs to sit inside a site you already have | It is the whole product, standing alone |
| You want normal web analytics on it | You need native hardware features |
| Reach matters more than maximum fidelity | Fidelity is the product |
Most business cases we see sit clearly on the left, and the people asking are often surprised, because they had assumed immersive work meant an app by definition.
What this looks like when it is built
Rather than describe it, open one. These are live, in a browser, with nothing to install.
- Simam Immerse — a headset-grade immersive media player that arrives as a link: a spatial lobby you walk through and a catalogue of 360° and 180° titles. The same build runs on Quest and Vision Pro and needs no store submission.
- Product configurator — web interface around a 3D viewer, the pattern most product and manufacturing briefs turn out to want.
- Virtual walkthrough — spatial navigation of a captured real environment.
Open them on a laptop first to see what most of your audience will get, then in a headset if you have one to hand. The difference between those two experiences is the thing to design around.
Five questions to answer before writing a brief
These decide the scope more than any technical choice does.
- Who opens it, and on what? If the honest answer is “mostly laptops”, design for the flat view and treat the headset as the upgrade.
- How do they get the link? Email, a QR code on a stand, a page on your own site, a login. This changes the first thirty seconds more than anything else.
- How long do you expect them to wait? That number sets the download budget, and the download budget sets what the content can be. Decide it before the visuals are signed off.
- What should it record? If nobody can say what the experience should tell you afterwards, it will not tell you anything.
- Who owns it in a year? Content that changes needs somebody to change it. This is where immersive projects quietly die.
Common questions
Does the person need a headset?
No. A WebXR page opens as an ordinary interactive 3D page on a laptop or a phone, and offers to enter the headset view only when there is a headset to enter. In practice most of your visitors will see the flat version, so it should be designed as the main experience rather than treated as a consolation prize.
Does it work on an iPhone?
The flat 3D view does. The immersive headset session does not: Safari on iPhone and iPad does not support WebXR. Apple Vision Pro does support it, which is a different Safari on a different operating system. Plan for the flat view being what an iPhone visitor gets.
Is it as good as a native headset app?
For product visualisation, walkthroughs, training scenarios, immersive video and brand experiences, the gap has closed to the point where most audiences would not notice. For a demanding game with heavy physics, or anything needing deep native hardware features, a native build is still better. The honest question is usually not which looks better, but whether the extra fidelity is worth the people you lose at the install step.
Do we need Unity for this?
No, and often it is simpler not to. Unity has no official WebXR support, so that route runs through a community package. Web-native engines target WebXR directly. If you already have a Unity project the calculation changes, which is what our comparison guide is for.
How long does one take to build?
It depends far more on how much content there is than on the technology. A single-scene product experience is a short engagement; a catalogue with a spatial interface is a longer one. Our pricing page sets out the bands, and we would rather scope it against your actual content than guess.
Will WebXR still be here in five years?
It is a W3C standard rather than one company’s product, it ships in Chrome, Edge, the Meta Quest browser and Safari on Vision Pro, and Meta now publishes its own WebXR framework built on the web stack. That is a reasonable footing. The honest caveat is that Safari on the desktop and Firefox still ship it switched off, and closing that gap is not currently scheduled work by the browser vendors, so plan around today’s support rather than a promised convergence.
Related guides
- WebXR vs Unity — if you are deciding what to build on, rather than whether to.
- Unity to WebXR: a practical migration guide — if you already have a Unity headset application.
- The state of XR and spatial computing in 2026 — the wider picture, including the hardware.
- Immersive XR and spatial applications — what we build, and how an engagement starts.