WebXR is the web standard that lets websites present virtual reality and augmented reality experiences directly in a browser, using JavaScript to access headset displays, tracking and input. In XR development within extended reality, it is the main way to deliver immersive content without an app store or installation: the user opens a link and enters the experience.
The core specification is the WebXR Device API, developed by the W3C Immersive Web groups as the successor to the earlier, experimental WebVR API. It covers VR and AR in one interface, while a set of optional modules adds features such as hit testing, anchors, hand input and layers. WebXR does not render anything itself; it provides poses, views and input, and the page draws the scene with WebGL, usually through a 3D framework.
How WebXR works in the browser
A WebXR experience starts on an ordinary web page. The page checks support through navigator.xr, and after a user gesture, such as a click on an Enter VR button, calls requestSession with a session mode. The browser asks for permission where needed and switches the headset or phone into immersive presentation.
Once the session runs, the browser calls the page’s frame callback through the session’s own requestAnimationFrame at the device’s native refresh rate, often 72-120 Hz on headsets. In each frame, the page reads the viewer pose relative to a chosen reference space, receives one view per eye with its projection matrix, and renders into an XRWebGLLayer that the browser composites and sends to the displays.
The browser, not the page, owns tracking, timing and compositing. This keeps latency-critical work in native code and allows the browser to apply reprojection when a frame is late, which protects comfort even when page rendering is slower than ideal.
Session modes and reference spaces
WebXR defines three session modes that determine how the content is presented. Choosing the right mode is the first design decision of any WebXR project.
| Session mode | What the user sees | Typical device |
|---|---|---|
inline | 3D content inside the normal page | Any browser, including desktop |
immersive-vr | Fully virtual scene in the headset | VR headsets, mixed reality headsets |
immersive-ar | Virtual content over the real world | AR-capable phones, pass-through headsets |
A reference space defines the coordinate origin for poses. The choice decides whether the experience is seated, standing or room-scale, and what the browser must support.
| Reference space | Origin | Suitable for |
|---|---|---|
viewer | The user’s head | Head-locked content and inline views |
local | Head position at session start | Seated experiences |
local-floor | Floor level near the start point | Standing experiences |
bounded-floor | Floor with a known safe area | Room-scale experiences |
unbounded | World-scale origin | Large areas and walking AR |
WebXR compared with native XR development
WebXR competes with native development stacks such as OpenXR-based engines and platform SDKs. Its advantages are reach and frictionless access, while native development offers deeper hardware access and higher performance.
| Aspect | WebXR | Native development with OpenXR or platform SDKs |
|---|---|---|
| Distribution | A URL, no install | App stores or sideloading |
| Updates | Instant on page reload | Store review and download |
| Cross-device reach | Any supporting browser | Separate builds per platform |
| Performance | Good for moderate scenes | Highest, full GPU control |
| Hardware features | Core and modular features | Full platform features, often earlier |
| Offline use | Limited, through caching | Fully supported |
| Monetization | Web payments, no store share | Store purchases and subscriptions |
OpenXR and WebXR are complementary: OpenXR is the native runtime interface used by engines, while browsers often implement WebXR on top of an OpenXR runtime. The choice between them depends on whether access and sharing or maximum fidelity matter more.
Building with WebXR in practice
Few teams program WebXR directly. Most use a 3D framework that wraps sessions, controllers and rendering. Common choices include three.js for flexible low-level control, Babylon.js for a full-featured engine, A-Frame for declarative scenes written as HTML-like elements, and PlayCanvas for an editor-based workflow.
Several practical requirements apply to every project:
- Serve the page over HTTPS, because WebXR is available only in secure contexts.
- Start sessions from a user gesture, since browsers block automatic entry into immersive mode.
- Request optional features explicitly, such as
hand-tracking,hit-testoranchors, and handle their absence. - Keep draw calls and texture sizes low, especially for standalone headsets with mobile GPUs.
- Provide a non-XR fallback, such as an inline 3D view, for unsupported browsers.
Browser support is strongest in Chromium-based browsers on Android and on headsets, including the browsers of major standalone headsets. Safari on visionOS supports immersive VR sessions, while support on desktop browsers and on iPhone is limited or absent, so feature detection is mandatory.
Limitations and common pitfalls
The main limitations of WebXR are performance headroom and uneven feature support across browsers. The table lists typical problems and their remedies.
| Problem | Cause | Fix |
|---|---|---|
| Enter VR button does nothing | Page served over plain HTTP | Use HTTPS, including in testing |
| Stuttering in the headset | Too much geometry or large textures | Reduce draw calls, compress textures |
| Content at wrong height | Unsuitable reference space | Use local-floor for standing content |
| AR fails on some phones | No immersive-ar support | Detect support and offer a 3D fallback |
| Long initial wait | Large assets downloaded at start | Stream and compress assets progressively |
WebXR also has no built-in store, accounts or discovery, so developers must plan how users find the experience. Links from existing websites, QR codes and headset browser bookmarks are the usual entry points.
Put simply
WebXR lets a web page become a virtual or augmented reality experience. You open a link in your headset or phone browser, press a button, and the page surrounds you instead of sitting in a flat window.
Nothing has to be installed, and updates arrive as soon as the page reloads. It is like a website for VR: easy to share and open, though usually less detailed than a full app built for one device.
In practice
A furniture retailer wants customers to see a sofa at true size in their own living room before buying. Building separate native apps for several phone platforms and headsets would require multiple teams and store approvals.
The development team builds a single WebXR page with three.js. On AR-capable phones and pass-through headsets, it starts an immersive-ar session, uses hit testing to find the floor, and places a compressed 3D model of the sofa where the customer taps. On unsupported browsers, the same page shows an inline 3D viewer that can be rotated with a finger or mouse.
The result is one codebase reachable from every product page through a View in your room button. The team updates models and fixes bugs by redeploying the website, and customers never need to download an app.