WebXR Browser and Headset Support

Meta Quest (Quest 2, Quest 3, Quest 3S, Quest Pro)

The Meta Quest family provides the broadest and most feature-complete WebXR implementation available. The Quest Browser is based on Chromium and receives regular updates, often adding new WebXR modules within months of their specification finalization.

Supported session types: immersive-vr, immersive-ar (passthrough), and inline. The Quest 3 and Quest 3S deliver full-color passthrough AR with environmental awareness, while the Quest 2 provides grayscale passthrough with more limited spatial understanding.

Input: 6DoF tracked controllers with trigger, grip, thumbstick, and face buttons. Hand tracking with 25 joints per hand. The Quest 3 supports simultaneous controller and hand tracking, meaning the player can put down one controller and use their free hand while still using the other controller. The Quest Pro adds eye tracking, though this is not currently exposed through WebXR in the browser.

AR modules: Hit testing, plane detection (horizontal and vertical with semantic labels), spatial anchors (including persistent anchors that survive across sessions), depth sensing (CPU and GPU modes), and mesh detection for room geometry. The Quest 3 is the most capable WebXR AR platform available.

Performance: The Quest 3 runs a Snapdragon XR2 Gen 2 with an Adreno 740 GPU, supporting 90Hz or optional 120Hz rendering. WebXR content on Quest 3 can deliver visually impressive experiences when optimized. The Quest 2 is more limited with its XR2 Gen 1, targeting 72Hz or 90Hz. The Quest 3S sits between the two with XR2 Gen 2 but a lower resolution display.

Limitations: The Quest Browser's WebGL implementation has lower limits for some parameters compared to desktop Chrome, particularly maximum texture sizes and framebuffer dimensions. Thermal throttling under sustained load is a real concern, especially for graphically intensive games played for more than 10 to 15 minutes.

Apple Vision Pro

Apple joined the WebXR ecosystem with visionOS 2, enabling WebXR support in Safari by default. This was a significant addition because it brought a high-end spatial computing device into the browser-based XR world.

Supported session types: immersive-vr (full immersion mode) and immersive-ar (shared space with transparent display). Safari on visionOS also supports inline sessions.

Input: The Vision Pro uses a gaze-and-pinch input model that is unique in the WebXR ecosystem. The player looks at an interactive element, and Safari reports a transient-pointer input source when the player pinches their fingers. There are no handheld controllers. Hand tracking is available through the WebXR hand input module, providing joint positions, though Apple restricts certain hand tracking data for privacy reasons (finger joint positions are available, but detailed hand mesh geometry is not).

AR modules: Safari on visionOS supports hit testing and basic spatial awareness, but does not expose the full set of AR modules available on Quest. Plane detection, depth sensing, and mesh detection have limited or no support in Safari's WebXR implementation. Apple's spatial computing model gives apps a different relationship with the environment compared to Quest's passthrough approach.

Performance: The M2 chip is the most powerful processor in any current XR headset, providing significantly more GPU and CPU headroom than the Quest 3. However, the display resolution is extreme at roughly 23 million pixels across both eyes, so the per-pixel shader budget is actually tighter than the raw GPU power suggests. Fragment shader complexity must be managed carefully.

Limitations: No controller support means games designed around trigger-and-grip interaction need substantial redesign for gaze-and-pinch. The privacy-first approach limits environmental sensing compared to Quest. Safari's WebXR implementation is newer and less battle-tested than Chrome's, so edge cases and spec compliance gaps are more common.

Desktop VR (Chrome and Edge on Windows)

Chrome and Edge on Windows support WebXR for PC-tethered headsets through OpenXR. Any headset that works with SteamVR or Windows Mixed Reality can run WebXR content in the desktop browser.

Supported devices: Valve Index, Meta Quest (via Link cable or Air Link), HP Reverb G2, Bigscreen Beyond, Pimax headsets, and all Windows Mixed Reality headsets. The common thread is OpenXR support, which Chrome and Edge use as their backend for WebXR on desktop.

Input: Full 6DoF controller support with device-specific button layouts. The desktop browser receives the same controller data as any native OpenXR application. Hand tracking is supported when the underlying runtime provides it (Quest via Link supports hand tracking, Ultraleap controllers provide hand tracking for other headsets).

AR modules: Desktop VR is primarily a VR platform. AR sessions are not available through desktop Chrome or Edge since the headsets connect in VR mode through OpenXR. Passthrough AR on a Quest via Link is handled by the Quest's own runtime, not the desktop browser.

Performance: Desktop is the most performant WebXR target by a wide margin. A dedicated GPU (RTX 4070 or better) handles WebGL rendering effortlessly at 90Hz or 120Hz. The bottleneck shifts from GPU to CPU, where JavaScript execution speed, garbage collection pauses, and draw call submission overhead become the limiting factors.

Limitations: Requires the player to own a PC with a dedicated GPU and a tethered or wirelessly connected headset. The setup is more complex than standalone headsets. Firefox dropped WebXR support in 2023 and has not restored it, so Chrome and Edge are the only desktop browser options.

Android (Chrome)

Chrome on Android supports WebXR for AR experiences through ARCore. This is a phone-based AR mode where the device's camera provides the real-world view and your content is overlaid on the screen.

Supported session types: immersive-ar and inline. Immersive-vr is not supported on phones since there is no headset to render to (the cardboard era of phone VR is effectively over).

Input: Screen touch is the primary input, reported as a transient-pointer input source. The player taps the screen to select, and the browser generates select events at the tap location. There are no controllers or hand tracking in phone AR mode.

AR modules: Hit testing (using ARCore's surface detection), plane detection (horizontal and vertical surfaces), and basic depth estimation (using ARCore's Depth API on supported devices). Anchors are supported on some devices. The feature set is smaller than Quest but covers the essentials for placing objects on surfaces.

Performance: Phone GPUs vary enormously. Flagship phones (Snapdragon 8 Gen 3, Dimensity 9300) can handle moderately complex WebXR AR scenes. Mid-range phones struggle with anything beyond simple geometry. Thermal throttling is aggressive on phones, and sustained AR camera usage drains the battery quickly.

Limitations: No VR support. AR features are limited to what ARCore provides. The experience is a handheld "magic window" rather than immersive head-tracked AR. Screen size limits the game design compared to headset AR where virtual content fills the visual field.

iOS (Safari on iPhone and iPad)

Safari on iOS does not support the WebXR Device API. There is no immersive-vr, no immersive-ar, and no access to ARKit through the browser. Apple has not announced plans to add WebXR to iOS Safari, and this situation has persisted for years.

This is the single largest gap in WebXR device coverage. iOS represents roughly 27% of global mobile traffic and over 50% in the United States. Any WebXR game that targets mobile users must account for the fact that a significant portion of their audience simply cannot access the immersive experience.

Workarounds: Use the inline session type to provide a flat 3D preview on iOS. The player sees the 3D scene in a standard browser viewport and can look around by tilting their device (using the DeviceOrientation API, which Safari does support). This is not AR or VR, but it gives iOS users something rather than nothing. For games that require immersive mode, clearly communicate that a headset or Android device is needed.

Apple's strategy appears to reserve immersive experiences for the Vision Pro, where Safari does support WebXR. Whether WebXR will eventually come to iOS remains unknown.

Feature Detection in Practice

Given the uneven feature coverage across devices, your WebXR game must detect available capabilities at runtime and adapt. The pattern is straightforward: check navigator.xr.isSessionSupported() for each session type, request optional features when creating the session, and check which features were granted.

Build your game in layers of capability. The base layer works with just immersive-vr and basic controller input, which covers every VR-capable device. The second layer adds hand tracking when available, expanding interaction options. The third layer adds AR features (hit testing, planes, anchors) when running on AR-capable devices. The fourth layer adds enhancements like depth occlusion and persistent anchors on devices that support them.

This progressive enhancement approach maximizes your audience while taking advantage of the best features available on each platform. A player on a Quest 3 gets the full experience with AR surface placement and depth occlusion. A player on a Valve Index gets a great VR experience with controller interaction. A player on an iPhone gets a flat 3D preview with touch interaction. Each player gets the best experience their device can deliver.