TL;DR: Web AR runs an augmented reality experience straight in a phone's browser, so a customer taps a link or scans a QR code and the content appears in their room with nothing to install. That reach is the entire point, and it is bought with real limits: lighter scenes, shorter sessions, less precise tracking and capability that varies by platform. Web AR is the right call for product visualization, packaging, campaigns and one-off public experiences. A native app or a headset build is right when tracking accuracy, persistence, offline use or shared anchors carry the value. Here's how to tell which one your project is, before you spend a budget finding out.
Almost every AR conversation eventually reaches the same question. Someone has an idea for letting customers see a product in their own space, and then a quieter question arrives: are we really going to ask people to download an app for this?
That question deserves more weight than it usually gets. Every step between seeing a promotion and using it costs you people, and an app install is a large step: a store visit, a download over whatever connection they have, an account in many cases, and enough motivation to see all of it through. For a customer standing in a shop, holding a package or looking at a poster, that is often the end of the story.
Web AR removes that step entirely. The trade is real, and worth understanding properly rather than being sold in either direction.
What web AR actually is
Web AR means the augmented reality experience is delivered by a web page. The user taps a link, scans a QR code or lands from an ad, the browser opens, and the camera view appears with digital content placed in the real world. Nothing is installed, and when the tab closes the experience is gone.
In practice there are three delivery routes, and they are not interchangeable.
Platform 3D viewers
The lightest option is a 3D model on a web page with a "view in your space" action that hands off to the phone's built-in AR viewer. You publish one optimized model, the platform handles placement, and the user gets a solid look at a product at true scale on the floor or against a wall. It is the cheapest route by a wide margin and covers a large share of the product-visualization requests we hear. The limit is that you get placement and inspection, not a designed interactive experience.
A real AR session in the browser
The browser can also run the AR session itself, so you control the interaction: tapping objects, configuring a product, stepping through a sequence, reacting to what the user does. This is where web AR starts to feel like an application rather than a viewer. The catch is that capability and browser support differ across platforms and shift over time, so confirm what your target devices support at build time rather than trusting a feature table from last year. Treat anything that only works on some phones as an enhancement, never as the thing your campaign depends on.
A native app
The full-capability route, chosen when the experience needs more than a browser will responsibly give it. Everything a phone's AR framework can do is available, assets can be heavy because they ship with the app, and the session can be long. You pay for it in reach, since every user has to install first.
The mistake we see is not picking the wrong one of those three. It is never comparing them, and defaulting to whichever the first vendor happened to build.
Where web AR genuinely earns its keep
Web AR performs when the value comes from a quick, in-context look at something and the audience is a member of the public who has never heard of you.
Product visualization and fit. Furniture, appliances, fixtures, equipment, anything where the real question is "will this work in my space." Seeing an object at true scale against a real wall answers a question a photo cannot, in the moment the purchase decision is live.
Packaging, print and physical placement. A QR code on a box, a shelf edge, a poster or an exhibition panel is a natural web AR trigger, because the person is already standing in front of the thing and holding a phone. An app download at that moment is a wall, and a link is not.
Campaigns and events. Short-lived experiences justify short-lived delivery. If something exists for a two-week promotion or a three-day conference, getting an app approved, installed and later maintained is disproportionate to its life.
Internal show-and-tell of 3D content. Sending a colleague or a client a link that puts a design at real scale in their office is often more persuasive than any render, and it takes a page rather than a project.
The common thread: the experience is short, the content is one object or a small scene, and the audience is uncommitted.
Where web AR hits its ceiling
The limits are not opinions, they are consequences of running inside a browser tab on a phone.
Tracking precision. Browser AR is good at putting an object on a floor and keeping it there while someone walks around it. It is not the tool when an overlay must stay locked to a specific piece of real machinery through movement and awkward lighting, which is the entire problem enterprise AR training has to solve.
Persistence and shared anchors. Content that must stay in a fixed real location across sessions, or that several people must see in the same place at the same time, needs infrastructure a page-load experience does not carry. That is why mixed-reality collaboration work like MR Camera, our multiplayer environment where several users place and interact with 3D models in one shared space, belongs on headsets and native builds.
Scene weight. Everything has to arrive over a phone connection before anything happens. A native app ships its assets once. A web AR page pays the download every time someone opens it, which puts a hard ceiling on model complexity and scene size.
Deep platform capability and live data. When the experience depends on precise geolocation, continuous sensor access, background processing or a live data pipeline, native is usually the honest answer. Planes XR, which we built for ARCortex, runs real plane simulations in the real world using AR and live OpenSky data. That is a native build for good reasons, and the same logic runs through location-based AR generally.
Measurement-grade accuracy. If the output is a number someone will act on, the device and the software stack are the product. Nystag, our VR eye-tracking diagnostics build, runs on a Vive Focus 3 precisely because the measurement has to be defensible. No browser experience competes there, and it should not try.
The four things that decide whether a web AR project works
1. The 3D assets, which are usually the real project
The model your product team already has is a CAD file or a marketing render, not a web asset. Getting from one to the other means retopology, sensible materials, baked lighting where it helps, and export in the formats phones expect. Multiply that by a catalogue and asset preparation becomes the largest line in the budget, not the AR code. A vendor who never asks how many products you have and what state the source files are in has not scoped the project.
2. Load time on a real connection
A web AR experience competes with the user's patience on cellular data in a shop. Every megabyte is a percentage of people who leave before the camera opens. Compression, level of detail and something meaningful on screen while the model streams are not polish, they are the difference between a link people use and a link people abandon.
3. A genuine reason to open the camera
The most common failure is a technically fine experience nobody wanted. AR earns its place when seeing something in the real world changes a decision: does it fit, how big is it really, what does it look like against my wall. If a good photo would have done the job, build the photo. We would rather say that early than ship something admired once in a meeting and never used again.
4. Distribution, which is a design decision not an afterthought
A web AR experience is a link, and links only work where people encounter them: the QR code on the packaging, the button on the product page, the code on the shelf edge, the sign at the stand. Decide where the trigger lives at the same time as the experience, because placement changes what the experience should be. Someone scanning in a shop aisle has thirty seconds. Someone opening a link from your product page at home has several minutes.
How to choose, quickly
Work through these in order and the decision usually makes itself:
- Is the audience the general public, or a known group you can equip? Public points at web AR. A known group can install something.
- Is this a look, or a task? Inspecting an object is web AR. Performing guided work on real equipment is not.
- Does anything need to persist, or be shared live? If yes, you are in native or headset territory.
- How heavy is the scene, honestly? One product, fine. A detailed environment, no.
- How long does this need to live? A campaign favours the web. A capability you will run for years justifies an app.
If the answers push you off the phone entirely, the next decision is which device class you are actually building for, which we work through in our XR device selection guide.
If web AR clears those and you still want a native app, that is a legitimate choice, but make it on the strength of retention and repeat use rather than on capability you will not use.
What it costs and how we scope it
Software cost follows the same drivers as any XR build, which we break down in what an XR app costs and how it's scoped. Web AR usually lands at the lower end, with one adjustment: the asset pipeline carries more of the budget than clients expect, and interactive browser sessions cost meaningfully more than a placement viewer.
Our approach is short and deliberately unromantic. Pick one product or one moment that matters. Prepare a single asset properly and test it on real phones over cellular data, not office wifi. Prove the trigger works where it will actually live, on the packaging or the page. Then decide whether to scale the catalogue, add interactivity or move to a native build, using evidence instead of a hunch. That is the same discipline behind how we ship in days rather than months: make the risky thing real early, cheaply.
Questions worth asking any web AR vendor
- What state do our 3D source files need to be in, and who prepares them?
- What will this weigh, and how long does it take to open on cellular data?
- Which devices and browsers is this guaranteed on, and what degrades gracefully elsewhere?
- Where does the trigger live, and who owns keeping that link working?
- What happens when we want a hundred products instead of one?
- What would push this to a native app, and how would we know we had crossed that line?
That last question is the one that separates a partner from a supplier. Anyone who says a browser can do everything a native AR app can do is selling, and the place that bill arrives is the middle of your build.
The bottom line
Web AR is not a cut-down version of real AR. It is a different trade: you give up tracking precision, persistence, scene weight and platform depth, and you get every phone that can open a link. For product visualization, packaging, campaigns and public experiences that is a very good trade, and the absence of an install is often the only reason the project works at all. For guided work on real equipment, measurement, shared spaces or anything that must hold its position across sessions, the browser is the wrong container and no amount of optimization changes that. Decide which one you have before you commission the assets, and the rest of the project gets much easier.
Weighing web AR against a native build? Book a demo and we'll tell you honestly which one your idea needs, including when a good product page beats both. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking, and MR Camera shared mixed reality.