AR/VR
Web AR and WebXR
Burger King ran a campaign where users pointed their camera at a competitor's ad and, in the browser - without installing anything - it burst into flames in AR. This was made possible via WebXR and image tracking. Developers spent less time on the AR implementation than on legal sign-offs.
- **Gucci AR Try-On** - sneaker try-on in the browser via 8thwall on iOS and Android
- **Shopify AR** - 3D product view on a real table via WebXR
- **Google Search AR** - 'View in AR' directly from search results
- **WebXR Samples** - official Google examples: hit-test, light-estimation, DOM overlay
WebXR Device API: AR as a W3C standard
Native ARKit/ARCore apps require installation from a store. But what if a user scans a QR code on an ad poster and immediately sees a 3D product model overlaid on the real world - without installing anything? That scenario is what the **WebXR Device API** solves - a W3C standard built into the browser.
WebXR provides a unified interface for VR and AR. The key objects for AR: **XRSession** (interaction session with the device), **XRReferenceSpace** (coordinate system - `local`, `local-floor`, `unbounded`) and **XRFrame** (snapshot of state for the current frame).
**Hit test** is the key AR feature: the user taps the screen, the browser raycasts into the real world and returns the intersection point with a surface. Without hit test it is impossible to place an object on a floor or table.
What is XRReferenceSpace in WebXR?
Three.js + WebXR: 3D objects in the real world
Working directly with WebGL and WebXR is verbose. Three.js - the most popular WebGL library - has built-in WebXR support. Setting `renderer.xr.enabled = true` is enough for Three.js to take over the render loop, camera matrices, and layers.
Three.js automatically updates **camera** matrices from XRFrame - no need to manually read device head/pose position. In AR mode the Three.js `camera` already contains the correct projection matrix from the device camera and its world position.
Why set `renderer.xr.enabled = true` in Three.js?
8thwall: AR where WebXR does not reach
The problem: as of 2024 WebXR `immersive-ar` is supported in Chrome on Android, but **Safari on iOS does not support immersive-ar at all** (only WebVR via QuickLook or limited inline mode). This cuts off half of mobile users. **8thwall** - a paid platform (Niantic) - implements AR entirely in JavaScript on top of the camera stream.
8thwall embeds its own SLAM engine in the browser: it obtains the video stream via getUserMedia, analyzes feature points using WASM code, and builds a world map - all in JS. This is significantly slower than native ARKit but works in Safari on iOS 14+.
8thwall powers major marketing campaigns: Gucci AR sneaker try-on, NFL AR masks, Pepsi AR activations. When reach matters more than performance, JS-SLAM in the browser is a reasonable trade-off.
What is the main advantage of 8thwall over native WebXR?
Browser AR constraints
Browser AR opens a new access channel, but imposes real limitations compared to native apps. Knowing them enables informed architectural decisions.
| Aspect | Browser (WebXR) | Native (ARKit/ARCore) |
|---|---|---|
| Persistent anchors | No (session ends - anchor gone) | Yes (ARWorldMap, Cloud Anchors) |
| LiDAR / depth | No JS access | Full access |
| Frame rate | 60 fps (with effort) | 60-120 fps stable |
| Face tracking | MediaPipe (ML, less precise) | TrueDepth (hardware) |
| Raw IMU access | DeviceMotion API (limited) | Full access |
| Installation | Not required (URL) | App Store / Google Play |
**Sandbox constraints**: a WebXR session cannot access room geometry, ARCore Depth API, or Face Anchors with blend shapes - only what the browser API explicitly exposes. This is intentional for privacy.
Persistent anchors are the key missing piece in Web AR. If the user closes the tab and reopens the page, all placed objects are gone. The experimental WebXR Anchors API appeared in Chrome 85 but has not gained broad support. For persistent AR, native apps or 8thwall with server-side position storage are needed.
WebXR and native AR do roughly the same thing, only WebXR runs in the browser
WebXR is a reduced public API on top of native capabilities. Persistent anchors, LiDAR, raw depth, and full face tracking are only available natively
The browser is a sandbox with strict sensor access restrictions. Full LiDAR access would allow building detailed room maps without user awareness
Why does browser AR not have access to LiDAR on iPhone 12 Pro?
Web AR and WebXR
- WebXR Device API is the W3C standard for AR/VR in browsers: XRSession, XRReferenceSpace, hit-test for object placement
- Three.js simplifies WebXR with `renderer.xr.enabled = true` and ARButton helper
- 8thwall implements AR entirely in JS/WASM to reach Safari on iOS, where immersive-ar is not supported
- Browser AR lacks persistent anchors, LiDAR, and precise face tracking - intentional sandbox constraints
Related topics
Web AR sits at the intersection of AR development and the web platform.
- ARKit and ARCore — The native layer that WebXR wraps in a browser API
- WebGL and 3D in the browser — Rendering AR scenes via Three.js/WebGL
Вопросы для размышления
- How does the persistent anchors limitation affect the types of applications that are realistic to build with WebXR?
- In which business scenarios is 8thwall justified over native AR despite the additional licensing cost?
- How does the browser sandbox model's restriction on depth data access relate to the broader principles of privacy by design?