WebXR Compatible Browsers: What Works Where

Because this table changes as browsers ship updates, treat it as a starting point for planning, not a permanent guarantee. Verify current behavior against the target device before committing to a launch date.

From JavaScript, check support before offering an "Enter VR/AR" button rather than showing it unconditionally:

if (navigator.xr) {
  const vrSupported = await navigator.xr.isSessionSupported('immersive-vr')
  const arSupported = await navigator.xr.isSessionSupported('immersive-ar')
}

On Quest, WebXR works out of the box in the Meta Quest Browser, with no setting to enable. On Android Chrome, AR features generally require Google Play Services for AR (ARCore) to be installed, which most modern Android devices already have or install automatically on first use. There is no "enable WebXR" toggle to hunt for in most current browsers. If isSessionSupported returns false, the device or browser genuinely doesn't support it, rather than it being switched off somewhere.

Since the single largest mobile audience (iPhone) has zero WebXR support, any project that needs to reach "everyone" needs a real fallback strategy, not an afterthought:

• A non-immersive 3D viewer as the default experience, with the WebXR session as an enhancement for capable devices. Most visitors will use this path, so it should be the one that's actually polished.
• AR Quick Look (USDZ file) for a native-feeling AR view on iOS specifically, launched by a plain link, separate from the WebXR/AR code path entirely.
• Clear, honest messaging. "View in AR" buttons that silently fail on unsupported devices are worse than not offering the feature; check support first and show the right call to action per device.