WebXR in 2025: Browser AR That Actually Works

For years, WebXR sat in that awkward middle ground—ambitious enough to excite developers, immature enough to frustrate them. 2025 is different. The spec is stable, browser support has crossed critical thresholds, and we're seeing genuine production deployments. If you've been waiting for a signal to take WebXR seriously, it's here.

Why Now?

Spec Stability and Browser Consensus

The WebXR Device API reached candidate recommendation status, and that matters. Chrome, Safari, and Firefox now ship compatible implementations. More importantly, the gaps between them have shrunk. You're no longer building against moving targets—you're building on a foundation that won't collapse six months from now.

Device support has expanded too. You're no longer limited to flagship phones or expensive headsets. Mid-range Android devices handle AR sessions with acceptable performance, and iOS support through Safari means your content reaches both ecosystems without native app overhead.

Performance Barriers Fell

WebGL 2.0 and WebGPU have made processing real-time video streams and rendering complex scenes directly in the browser genuinely feasible. A-Frame and Babylon.js have optimized for AR workflows specifically. What used to require native code—accurate plane detection, light estimation, occlusion handling—now runs in JavaScript.

Building Real AR Experiences

Getting Started: A Minimal Example

Here's what a basic AR session looks like:

typescriptCopy
const session = await navigator.xr.requestSession('immersive-ar', {
  requiredFeatures: ['hit-test', 'dom-overlay'],
  domOverlay: { root: document.body }
});

const gl = canvas.getContext('webgl2', { xrCompatible: true });
const glLayer = new XRWebGLLayer(session, gl);
await session.updateRenderState({ baseLayer: glLayer });

session.requestAnimationFrame((time, frame) => {
  const pose = frame.getViewerPose(refSpace);
  // Render your scene here
});

This is stable API surface. It won't change tomorrow. That reliability is new.

Production Considerations

Hit-test is non-negotiable for furniture placement and product visualization. Plane detection lets you understand the environment. Light estimation makes your virtual objects feel anchored to reality rather than floating.

typescriptCopy
const hitTestSource = await session.requestHitTestSource({
  space: inputSource.targetRaySpace
});

session.requestAnimationFrame((time, frame) => {
  const hits = frame.getHitTestResults(hitTestSource);
  if (hits.length > 0) {
    const pose = hits[0].getPose(refSpace);
    // Place content at hit location
  }
});

Dom overlay support means you can render HTML UI alongside your 3D scene. Your analytics, buttons, and data displays live in familiar territory. Your rendering pipeline handles the 3D.

Real-World Deployment Patterns

Companies shipping WebXR now typically follow this path:

• E-commerce: Furniture and eyewear visualization. No app install barrier. Works in Safari on iOS.
• Enterprise: Remote assistance and equipment inspection. IT departments prefer not managing app deployments.
• Education: Interactive anatomy and architectural models. Shared URLs beat classroom app coordination.

At LavaPi, we've seen teams move from experimental prototypes to customer-facing deployments within product cycles. The tooling matured. The confidence grew.

Difference between 2023 and 2025? Back then, questions were whether WebXR would work. Now they're about whether your pipeline supports multiple simultaneous hit tests or whether you need WebGPU for your specific compute requirements.

What Remains

It's not frictionless everywhere. Battery drain on extended sessions is real. Some AR features remain device-specific. Desktop WebXR for VR is solid; mobile AR still has gaps on some Android devices.

But the baseline—making AR work reliably in a browser without installation friction—is solved.

If you shelved WebXR projects waiting for stability, the conditions changed. The bet isn't speculative anymore.