WebAR

WebAR (also written Web AR, short for web-based augmented reality) is augmented reality delivered through a web browser instead of a native app that the user has to download and install first. A WebAR experience is opened from an ordinary link or QR code; the page uses the device camera, motion sensors and GPU to place virtual content over a view of the real world. In their 2019 survey in Proceedings of the IEEE, Xiuquan Qiao and colleagues contrasted it with hardware-based mobile AR, which they called costly and inflexible, and app-based mobile AR, which "requires additional downloading and installation in advance and is inconvenient for cross-platform deployment"; Web AR, by comparison, "can provide a pervasive AR experience to users" because the Web is a lightweight, cross-platform delivery platform.

There are three broad ways to build WebAR. JavaScript libraries can run their own computer vision tracking inside the page, as AR.js and 8th Wall did. Browsers can expose the device's native AR tracking through the W3C WebXR Device API and its Augmented Reality Module, which defines the immersive-ar session mode. A web page can also hand a 3D model to a viewer built into the operating system, such as Apple's AR Quick Look or Google's Scene Viewer. As of September 2026, the WebXR route works in Chromium-based browsers on Android and in the Meta Quest Browser on Meta headsets, but Safari on iPhone and iPad does not support WebXR at all.

Reviewed 27 September 2026. Checked the definition, W3C WebXR spec statuses, Chrome/Meta/Apple/Google support details, 8th Wall history and shutdown dates, AR.js and model-viewer docs, and the Qiao, Argon and China Communications paper details against the cited sources. About review dates.

Definition

Qiao et al. treat Web AR as a branch of Mobile AR and classify implementations by where the computation happens. A "self-contained" method "executes all tasks on the mobile device locally", which avoids network delay but is limited by the phone's computing power, "especially on the Web". A "computation outsourcing" method sends computer vision work to cloud or edge servers, which can give a better experience but makes the application depend on network conditions. The self-contained approach is divided further into pure JavaScript libraries or plug-ins and extensions of the browser kernel, in which the browser itself gains AR functions and applications can reach "near-native performance".

The same survey names the enabling web technologies: WebRTC for camera capture in the browser, WebAssembly for running compiled C and C++ code at close to native speed, WebGL for GPU-accelerated rendering, and Web Workers for background processing.

Approaches

JavaScript tracking libraries

Early browser AR libraries relied on printed markers; Qiao et al. note that fiducial tracking gives accurate and robust results because of its low computational complexity. Qiao et al. list JSArUco (a JavaScript port of ArUco), JSARToolKit (based on the original ARToolKit) and JSARToolKit5 (an Emscripten port of ARToolKit), and describe AR.js, introduced in 2017, as the state of the art at the time: a solution built on Three.js and JSARToolKit5 that ran in any browser with WebRTC and WebGL and reached 60 frames per second on a Nexus 6P, but which then supported only fiducial markers. AR.js was created by Jerome Etienne and is now maintained by the AR.js organization. Its current README describes it as "a lightweight library for Augmented Reality on the Web" with image tracking, location-based AR and marker tracking, offered in builds for A-Frame and Three.js; the AR.js code is MIT-licensed, while the bundled artoolkit5-js is under LGPLv3.

Markerless tracking in the browser came later. On 11 September 2018, 8th Wall announced 8th Wall Web, which it released first to selected brand partners. The company called it "the first solution of its kind for augmented reality (AR) in the mobile browser". Its SLAM engine was a 6DoF markerless tracking system with feature point extraction, sensor fusion, mapping, bundle adjustment and relocalization, loaded as an ordinary browser script and built on standard web technologies: the JavaScript MediaDevices API, the Sensor API, WebGL and WebAssembly. Nicholas Butko, writing as 8th Wall's director of engineering, said that the team transpiled its C++ SLAM code to asm.js and WebAssembly, moved work such as feature point detection from the CPU to WebGL because a web page has only one JavaScript thread, and reached 30 frames per second "even on some phones released four years ago".

WebXR Device API

The standards-based route is the WebXR Device API, developed by the W3C Immersive Web Working Group. The core specification, a Candidate Recommendation Draft dated 9 June 2026, defines the inline and immersive-vr session modes and leaves immersive-ar to a separate module. That module, the WebXR Augmented Reality Module Level 1 (Candidate Recommendation Draft, 25 April 2025), states that an immersive-ar session gets exclusive access to the XR device display and that its content "is intended to be blended with the real-world environment". It defines three environment blend modes: in "opaque" the rendered image is composited over black pixels, in "alpha-blend" it is composited over pixel representations of the real-world environment, and in "additive" it is composited with "lighter" blending. It also defines two interaction modes: "screen-space", in which user interface is drawn directly to the screen, and "world-space", in which it is drawn in the world some distance from the user for interaction with controllers.

Further modules add functions needed for AR. The WebXR Hit Test Module, a Working Draft of 11 December 2025, lets a page cast rays into the real environment and receive intersections with detected points, planes and meshes, so that virtual objects can be placed realistically in the user's surroundings. On Android, Chrome uses ARCore: Google's WebXR codelab requires an ARCore-capable device running Android 8.0 and Google Play Services for AR, and uses the immersive-ar mode with the hit-test and dom-overlay features. On Meta headsets, the Meta Quest Browser uses immersive-ar to turn on passthrough; Meta's documentation describes plane detection and persistent anchors (up to eight per site) for WebXR mixed reality, with passthrough in color on the Meta Quest Pro and in grayscale on the Meta Quest 2.

System AR viewers launched from the web

The simplest form of WebAR places a single 3D model in the room by passing it from the web page to a viewer in the operating system. Apple's AR Quick Look displays USDZ files, and Reality files for interactive scenes, from Safari and other built-in apps; it requires iOS 12 or iPadOS 12 or later, or visionOS 1 or later, and supports Apple Pay and custom action banners for retail use. Quick Look is a native viewer and not an implementation of WebXR. On Android, Google's Scene Viewer is launched from a website through a formatted intent URL and loads glTF 2.0 or GLB models; it needs an ARCore-supported device running Android 7.0 or later with current versions of Google Play Services for AR and the Google app, and falls back to a plain 3D view when AR is not available.

Google's open-source <model-viewer> web component combines these paths. Its ar-modes attribute is "a prioritized list of the types of AR experiences to enable", with the default "webxr scene-viewer quick-look": WebXR in the browser where supported, otherwise Scene Viewer on Android or Quick Look on iOS, and if no separate USDZ file is supplied for Quick Look, it generates one on the fly.

History

Research on AR inside web browsers predates the standards. At the IEEE International Symposium on Mixed and Augmented Reality (ISMAR) in 2011, Blair MacIntyre and colleagues presented the Argon AR web browser and a standards-based AR application environment. Qiao et al. list Argon with the RWWW browser and Wikitude as early browser-kernel extensions.

The arrival of ARKit and ARCore in 2017 led browser makers to build experimental AR browsers on top of them. Mozilla released its WebXR Viewer app for iOS in 2017, a developer tool that combined ARKit tracking with an early draft of WebXR; in June 2020 it released WebXR Viewer 2.0, rebuilt on the Firefox for iOS code base. Google published WebARonARCore for Android and WebARonARKit for iOS, "an experimental Chromium modification" that its README says "is not an official Google product" and whose JavaScript APIs "are not standards, or on the standardization path"; the repository was archived in 2022. In China, Baidu and Tencent both proposed Web AR solutions in 2017, DuMix AR and TBS AR. Qiao et al. warned that, until AR-capable browsers were standardized, the diversity of APIs offered by these browser extensions would limit large-scale use of Web AR.

Standardization moved to WebXR, which, unlike the older WebVR API designed only for VR, supports both VR and AR. In June 2018 Google wrote that it had announced the WebXR Device API for both AR and VR in Chrome 67, though only the VR features were enabled, and described early AR testing in Chrome Canary on Android phones with ARCore installed. The WebXR Device API shipped in Chrome 79 in late 2019, and Chrome 81 added AR session types and hit testing. Road to VR reported the Chrome 81 beta, with the WebXR Hit Test API, in February 2020.

8th Wall

8th Wall was founded in 2016 by Erik Murphy-Chutorian, and in March 2022 Niantic agreed to acquire it; TechCrunch reported that it was Niantic's largest acquisition to date and that the price was not disclosed. On 20 November 2025, the 8th Wall team announced that the service would shut down after seven years. Account creation, logins, project editing and exports ended on 28 February 2026; published projects stay online until 28 February 2027, after which hosting is decommissioned. In January 2026 Niantic Spatial released a Distributed Engine Binary that includes SLAM under a binary-only license, and it then published an MIT-licensed open-source engine framework with the Face Effects, Image Targets and Sky Effects modules but without SLAM.

Browser support

MDN marks the WebXR Device API as experimental and "not Baseline because it does not work in some of the most widely-used browsers", and the API is available only in secure (HTTPS) contexts. The Can I use compatibility tables in September 2026 list partial support in Chrome, Edge and Samsung Internet, with a note that many features are still in development; Firefox and desktop Safari support it only behind a flag or experimental setting, and Safari on iOS has no support.

When Safari in visionOS 2 turned on WebXR by default for Apple Vision Pro in 2024, support was limited to VR, without the Augmented Reality Module; Apple instead added a "transient-pointer" input mode to the standard for gaze-and-pinch input. Apple has also developed the HTML <model> element, which on Apple Vision Pro shows a stereoscopically rendered 3D model "in a portal inside your web page". WebKit's announcement says the element complements WebXR and Quick Look, and it was enabled by default in visionOS 26. With Safari 27.0, released in September 2026, the element also became available in Safari on iOS, iPadOS and macOS.

Research

Qiao et al. name computational efficiency, energy efficiency and networking as three important challenges, and propose collaborative approaches based on the osmotic computing paradigm, in which Web AR tasks are split between the terminal and the cloud, or among the terminal, network edge servers and the cloud. In a follow-up paper in China Communications (2019), the same group named "the low efficiency for dense computing in Web browsers, a large delay for real-time interactions over mobile networks, and the lack of standardization" as the main obstacles. They argued that 5G network slicing, device-to-device communication and mobile edge computing could reduce these problems, and they tested a service-oriented framework, MWAR5, on a 5G trial network.

See also

• WebXR
• WebVR
• 8th Wall
• A-Frame
• Three.js
• Babylon.js
• ARCore
• ARKit
• Mobile AR