WebXR Development

WebXR replaced WebVR and covers both ends of the spectrum through two session types:

• immersive-vr: the page renders to a headset. The browser hands you head pose, controller poses, hand tracking where supported, and a stereo framebuffer.
• immersive-ar: the page renders over a camera or passthrough feed. On a phone the scene sits on top of the camera view; on a passthrough headset it sits in the room. Additional modules cover hit testing against real surfaces, anchors, plane detection and depth.

What WebXR is not: it is not a rendering engine, and it is not AR tracking. The rendering is Three.js or another WebGL/WebGPU library. The world understanding is whatever the device's platform provides, which varies enormously between devices.

The property that matters is distribution. A link works in a message, an email, a QR code on packaging. No install, no review process, no 200 MB download before anyone sees anything. For a trade-show demo, a product experience or a training module, that is often worth more than the extra polish a native app would buy.

This is the section other pages leave out. Current state, plainly:

Works well

• Meta Quest Browser: the most complete WebXR implementation there is. Both session types, controllers, hand tracking, passthrough AR. Quest is realistically the primary target for browser VR.
• Android Chrome: immersive-ar on ARCore-capable phones, including hit testing for surface placement. This is the largest genuinely reachable AR audience on the web.
• Wolvic and other Chromium-based XR browsers: broadly compatible.

Works with caveats

• Apple Vision Pro (Safari on visionOS): supports immersive sessions with hand input, and it is a real target. Treat the specifics as something to test rather than assume; behaviour has moved between OS versions.
• Desktop Chrome or Edge with a tethered PC headset: works, but the population is small and the setup path is fragile.

Does not work

• Safari on iPhone and iPad. No WebXR. This is the single most important fact on the page, because it means an "AR in the browser" feature does not reach iPhone users through WebXR at all. The routes that do reach them are AR Quick Look with a USDZ file, or camera-based web AR built on computer vision rather than the WebXR API.
• Firefox. WebXR support was removed and has not returned.

So planning a project means answering one question first: is this for headset owners, for Android phones, or for everyone? Those are three different builds. "Everyone" means the model viewer is the product and the immersive session is a bonus for the minority who can enter it.

"Let customers see it in their room" is a common request and it has no single implementation.

Platform AR viewers. Android's Scene Viewer takes a glTF file; iOS Quick Look takes a USDZ. Both are launched by a link from a normal web page, both are essentially free to implement, and both are heavily optimised by the platform. The catch is two export formats maintained in step, and almost no control over what the experience looks like. You hand a file to the operating system.

WebXR immersive-ar. Full control, hit testing, your own interface, your own interactions. Android Chrome and passthrough headsets only. No iPhone.

Camera-based web AR. Computer vision over a plain camera feed: marker tracking, image tracking, face tracking. Works on iOS, because it uses the camera API rather than WebXR. This is what most branded AR filters and packaging campaigns use. It generally means a commercial SDK, it costs more, and tracking quality is below platform AR.

For most product work the pragmatic answer is the first: ship glTF and USDZ, launch the platform viewer, and spend the saved budget on the product configurator or visualization the AR view is launched from.

The scene is not the hard part. These are.

You render twice. Two eyes, every frame. Fragment work roughly doubles and the frame budget is tighter than on a screen: 72 Hz is a common floor and 90 Hz a common target, so a frame has around 11 milliseconds. Foveated rendering and multiview help, but the honest planning assumption is that a scene which runs comfortably at 60 fps on a monitor needs real work before it holds 90 fps in stereo on standalone hardware.

Dropped frames make people ill. On a flat screen a stutter is annoying. In a headset it is nausea. Frame rate is not a polish item to be addressed at the end; it is a design constraint from the first day, and it is the main reason VR scenes are visually simpler than their flat-screen equivalents.

Comfort rules the interaction design. Camera movement the user did not initiate, acceleration, and artificial locomotion all cause sickness in a meaningful share of people. Teleport movement, fixed vantage points and short sessions are the conservative defaults, and there are good reasons they are so common.

The interface is in the world. No DOM, no CSS, no accessibility tree. Every button is geometry, every label is rendered text, and legibility at distance becomes a real design problem. Everything that HTML gives you for free has to be rebuilt.

Input varies by device. Controllers on Quest, hands on Vision Pro and on Quest with hand tracking, a touchscreen in phone AR. An interaction model that assumes a trigger button excludes hand-tracked users entirely.

Testing needs the hardware. Browser emulators are useful for wiring, and they tell you nothing about comfort, legibility or frame rate. Budget for device testing on every device you claim to support.

A WebXR layer added to a 3D scene that already exists is a small piece of work: enable XR on the renderer, add an entry button, build controller and hand interaction, then spend the real time on comfort and performance testing.

A purpose-built immersive experience — an environment, spatial interface, spatial audio, guided flow — is a production, and it is priced like one.

The uncomfortable question is worth asking early: how many people will actually enter it? For a public marketing site, the number of visitors with a headset who will put it on for your page is small. That does not make the project pointless, and the honest justifications tend to be specific:

• Controlled contexts: a trade show, a showroom, a classroom, a training programme, where you supply the headsets and the audience is captive. WebXR is excellent here, and no-install distribution is exactly what you want.
• Android phone AR at scale: reaching a real audience, particularly from packaging or a QR code.
• The scene has a second life. If the same model already powers a configurator or a product page, an immersive mode is an increment rather than a project.

If a WebXR feature is being scoped mainly so a press release can mention it, I will say so. That is usually the cheapest advice I give.

Design the non-XR experience first and completely. Almost everyone will see it.

That means the same scene running as an ordinary interactive 3D view with orbit controls, on a page whose content is server-rendered HTML that reads perfectly with no JavaScript at all. The "Enter VR" button appears only when navigator.xr reports a supported session, never as a button that fails when pressed. If AR is offered on Android and not on iPhone, the iPhone visitor should see the platform's own AR Quick Look route or nothing, rather than a disabled control and no explanation.

Feature-detect every capability rather than sniffing user agents, since support varies by device, OS version and browser build in combinations no lookup table survives. And keep an escape hatch: a way out of an immersive session that does not require finding a controller, because someone will start a session by accident.

The VR and WebXR section of this site collects working examples worth studying before commissioning anything.

Promising iPhone AR through WebXR. It does not exist. This gets discovered late, and it invalidates whatever was demonstrated to stakeholders on an Android device.

A desktop scene shipped to a headset. Post-processing stacks, high-poly models and dynamic lights that are fine at 60 fps on a monitor produce a nauseating 45 fps in stereo. Rebuild the scene for the target, do not port it.

Interface designed for controllers only. Hand tracking is now common. A pointer-and-trigger interaction model leaves those users unable to press anything.

No testing on the actual device. Text that is legible in an emulator is unreadable at scale; a button placed comfortably in a simulator is behind the user's shoulder on hardware.

Motion the user did not ask for. Camera moves, forced locomotion and acceleration are the fastest way to make someone take the headset off and not put it back on.

Treating it as an install-free native app. WebXR trades some capability and performance for distribution. That trade is often correct, and pretending it is not a trade sets expectations the build cannot meet.