Which browsers support and its AR features?
Updated
<model-viewer> supports the last two major versions of all evergreen desktop and mobile browsers, plus the last two versions of Safari on macOS and iOS. That covers the basic 3D display. AR is a separate question: if you use WebXR in ar-modes, the browser also needs the WebXR Device API, the WebXR HitTest API, and the WebXR DOM Overlay API — and those are not uniformly available.
Browser support at a glance
| Browser | Basic <model-viewer> |
WebXR AR features |
|---|---|---|
| Evergreen desktop browsers (last 2 major versions) | Supported | Depends on WebXR API support |
| Evergreen mobile browsers (last 2 major versions) | Supported | Depends on WebXR API support |
| Safari on macOS (last 2 versions) | Supported | Depends on WebXR API support |
| Safari on iOS (last 2 versions) | Supported | Depends on WebXR API support |
"Evergreen" means browsers that update themselves automatically, such as Chrome, Edge, and Firefox. The support statement is version-based, not browser-name-based, so the practical rule is: keep the browser current and you are within the supported range.
What the WebXR requirement actually means
The three APIs listed in the documentation have different availability levels:
- Natively supported — the browser implements the API directly.
- Available with polyfill — the API is missing, but a polyfill can supply it.
- Behind a flag, unstable — the API exists but is not enabled by default and may change.
- Not available — the browser does not provide the API.
The documentation presents these as a feature matrix rather than a single yes/no answer, which is the key point: a browser can fully support <model-viewer> for 3D viewing while still failing on WebXR AR because one of the three APIs is missing or flagged.
How to check before you ship
- Identify which
ar-modesyou actually need. If you only need 3D display, the evergreen/Safari rule is your whole answer. - If you need WebXR, look up each of the three APIs — Device API, HitTest API, DOM Overlay API — in your target browser's support status.
- Where the status is "available with polyfill," plan to load the polyfill rather than assuming native support.
- Where the status is "behind a flag, unstable," treat that browser as unreliable for production AR and provide a fallback path.
- Test on the actual last-two-versions of your target browsers, since the support statement is explicitly version-scoped.
Practical takeaways
- For 3D-only use: the last two major versions of evergreen browsers and the last two Safari versions are enough. This is the widest and most predictable support tier.
- For AR via WebXR: verify the three WebXR APIs per browser. Expect a mix of native support, polyfill needs, and flagged/unstable implementations.
- For iOS Safari specifically: it is covered for
<model-viewer>itself, but WebXR availability is governed by the same API matrix, so do not assume AR works just because the component renders.
The safest approach is to treat 3D display and WebXR AR as two separate compatibility checks, and to design a non-AR fallback for any browser where the WebXR APIs are missing, polyfill-only, or flagged.