Every AR project I have scoped eventually arrives at the same quiet question, usually about twenty minutes into the kickoff call. Someone wants customers to see a product in their own room, we sketch the happy path, and then a person at the far end of the table says it out loud: are we really going to ask people to download an app for this?
That question deserves more weight than it usually gets, because the answer changes the entire build. And the trap on the other side of it is not the AR code. It is that your browser-based demo works perfectly on office wifi, on a flagship phone, with the asset already sitting in cache, and none of those three things are true for the person you built it for.
Web AR is three different things wearing one name
When a client says web AR, they could mean any of three delivery routes, and they are not interchangeable.
Route one: hand off to the phone's own viewer. You publish one optimized model, put a "view in your space" button on a page, and let the operating system do the AR. On iOS that path expects a USDZ file and opens AR Quick Look. On Android it expects glTF or GLB and opens Scene Viewer. The <model-viewer> web component wraps both handoffs plus an inline 3D preview, which means a competent front-end dev can ship this in an afternoon once the asset exists.
You get placement and inspection at true scale. You do not get an interactive experience, because you handed the session to someone else's viewer.
Route two: run the AR session in the page. WebXR, your own render loop, your own interaction. Tapping objects, configuring a product, stepping through a sequence, reacting to what the user does. This is where web AR stops being a viewer and starts being an application.
The catch is support. Browser AR capability differs across platforms and moves over time, so check what your actual target devices do at build time instead of trusting a feature table you read last year. My rule: anything that only works on some phones is an enhancement, never the thing the campaign depends on. Feature-detect, and have a real fallback that is not an apology page.
Route three: a native app. Full platform capability, assets ship with the binary, sessions can be long. You pay for it in reach, because every single user has to install first.
The mistake I see is almost never picking the wrong one of these. It is never comparing them, and defaulting to whichever route the first vendor happened to have built before.
Every byte is paid on every open
This is the part that separates web AR from every other 3D work you have done, and it is worth being blunt about.
A native app downloads its assets once, from a store, usually over wifi, while the user is willing to wait because they made a decision to install. A web AR page pays the download every time someone opens the link, over whatever connection they have, while standing in a shop, having made no commitment to you whatsoever.
That single difference sets a hard ceiling on your scene. Not a soft one you can optimize your way past later. So the engineering work is unglamorous and completely non-optional:
- Compress the geometry. Draco or meshopt on the glTF, and measure the decode cost on a mid-range phone, not just the transfer size.
- Compress the textures. KTX2 with Basis, so the GPU gets a compressed format instead of your app decoding a 4K PNG on a phone and holding the uncompressed result in memory.
- Ship the level of detail the moment needs. The 2 million triangle hero mesh is not the one that opens in an aisle.
- Put something meaningful on screen while it streams. A poster frame, a low-res proxy, a progress state that is not a spinner. People forgive loading. They do not forgive a blank camera view.
Then test the way the user will actually experience it. Real phones, cellular data, throttled, cache cleared. Every megabyte you leave in is a slice of your audience who close the tab before the camera opens, and you will never see them in your analytics as anything except a bounce.
The 3D assets are usually the real project
The other thing that gets scoped at zero: your client already has models, so that part is done. It is not.
A CAD file exists to manufacture an object. It carries exact surfaces, every internal fastener, every part nobody will ever see, and often the entire sub-assembly tree. A marketing render exists for one camera angle with lighting baked into the image. A photogrammetry scan arrives as one enormous messy lump of geometry with the lighting of the day it was captured burned in.
All useful starting points. None of them is a deliverable. Getting from any of them to a web asset means retopology, sensible real-time materials, baked lighting where it helps, and export into the formats phones expect. Then multiply that by a product catalogue and asset preparation becomes the largest line in the budget, not the AR code.
If a vendor has not asked how many products you have and what state the source files are in, they have not scoped the project. They have guessed at it.
Where the browser tab genuinely runs out
I am not writing this as a browser purist. Several of the builds I am proudest of had to be native, and it was not close.
Tracking precision. Browser AR is good at putting an object on a floor and keeping it there while somebody walks around it. It is not the tool when an overlay has to stay locked to a specific piece of real machinery through movement and bad lighting.
Persistence and shared anchors. Content that must hold a fixed real-world position across sessions, or that several people need to see in the same place at the same time, needs infrastructure a page load does not carry. MR Camera, a multiplayer mixed reality environment where several users place and interact with 3D models in one shared space, is on headsets for exactly that reason.
Live data and deep platform access. Planes XR, which we built for ARCortex, runs real plane simulations in the real world using AR and live OpenSky data. Continuous sensor access, precise geolocation, a live data pipeline. That is a native build for good reasons.
Measurement you will act on. Nystag, our VR eye-tracking diagnostics work, runs on a Vive Focus 3 because the number at the end has to be defensible. No browser experience competes there and it should not try.
The five questions that settle it
Run 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 the browser. 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 two-week campaign favours a link. A capability you will run for years justifies an app.
One more that gets skipped: where does the trigger live? 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 a shelf edge. Decide that at the same time as the experience, because it changes what you should build. Someone scanning in a shop aisle has thirty seconds. Someone opening your product page at home has several minutes. Those are two different apps.
The honest trade
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 in exchange you get every phone that can open a link. For product visualization, packaging, campaigns and public experiences that is a very good deal, and the missing install is frequently the only reason the project works at all.
For guided work on real equipment, for measurement, for shared spaces, or for anything that has to 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. Everything after that gets much easier.
The longer client-facing version of this, including how we scope the asset pipeline, is on the Null Studio blog.
Top comments (0)