Yes. A buyer can hold up their phone, point it at their own floor, and see your client’s product standing there at true scale, straight from a web page, with nothing to install. That has been true on both iPhone and Android for years.
What rarely gets said at the pitch stage is how much work “both” is doing in that sentence. iOS and Android arrive at the same result through two different systems that read two different file formats, and the open standard everyone assumes is doing the job is mostly not the one doing it. Scope an AR build as though the web has one AR and you will be one file format short — and you will find that out on the client’s phone, in the room, at the review.
Here is the shape of it before you quote.
There is no single “web AR”
There are three mechanisms, and which one fires depends on the device in the buyer’s hand.
On an iPhone, the browser hands the model to Apple’s AR Quick Look. On an Android phone, the browser hands it to Google’s Scene Viewer. WebXR — the actual W3C standard, the one that lets a site render AR itself rather than handing off — runs on some Android browsers and on desktop, and is the exception rather than the rule.
Nobody chooses between these. All three are in play on a public website, because your client’s buyers are not on one platform.
What iOS does
Apple’s AR Quick Look reads USDZ files. Apple’s own developer documentation puts it plainly: built-in apps including Safari, Messages, Mail, News and Notes use Quick Look to display USDZ files of virtual objects in 3D. It needs a device running iOS 12 or iPadOS 12 or later, or visionOS 1 or later.
No download, no app, no permission dialog beyond the camera. Tap, and the object is on the floor. It is a genuinely good experience, and it is the reason “AR on the web” became a sellable idea at all.
It will not read a GLB file.
What Android does
Google’s Scene Viewer reads glTF 2.0 / .glb, with the KHR_materials_unlit and KHR_texture_transform extensions. It needs Android 7.0 Nougat (API level 24) or later, a current version of Google Play Services for AR, and a current version of the Google app. Google’s documentation notes that most Android browsers support Scene Viewer.
Also no download. Also a good experience. It will not read a USDZ file.
So: two exports per product, every product, forever. That is not a rendering decision or a quality decision. It is a platform fact, and it belongs in the estimate rather than in the change order.
WebXR is the standard, and it is not the answer yet
This is where scopes go wrong, because WebXR is what shows up when you search for the technology behind web AR.
Support for the WebXR Device API currently sits at about 77% of global browser usage, per caniuse.com. The gap is the part that matters: iOS Safari does not support it, and desktop Safari and Firefox ship it switched off by default. Chrome on Android, Edge, Samsung Internet and Opera Mobile carry partial support.
Read that against the device your client’s buyer is most likely holding. If you have promised a WebXR experience to a customer base with iPhones in it, you have promised a thing that will not run. It is telling that even well-funded configurator vendors still ship WebXR marked “beta” on their top tier.
WebXR is where this is going. It is not where it is.
The component that hides the fork
The practical answer for almost every commercial build is Google’s <model-viewer> — an open-source web component, currently at version 4.3.1, released in June 2026.
It does two useful things. First, it renders the 3D model itself in the page, and plain 3D display is supported in all evergreen browsers, which is a much wider audience than AR. Second, it manages the handoff: src takes your GLB, ios-src takes your USDZ, and the ar-modes attribute declares the order of preference between webxr, scene-viewer and quick-look. Google’s documentation is explicit that if WebXR is not supported, Scene Viewer is used instead.
One element, two files, three mechanisms, and the buyer never learns any of that. AR itself still requires an ARCore-supported device with Google Play Services for AR installed, so a share of Android traffic will get the 3D viewer without the AR button. Plan the page so the 3D view is worth landing on by itself, because for a meaningful slice of visitors it is the whole experience.
What this does to the estimate
Two things drive the number: making the models, and running the viewer.
For the models, Sketchfab’s own enterprise guidance puts simple models at $40 to $200 and complex ones at $200 to $1,000, with very complex work running to a few thousand dollars. Those are per-model figures, and a configurator with twelve variants is not one model.
For the whole implementation, Plattar publishes a range of $3,000 to $500,000, which is honest and almost useless — it is a range that includes a single product viewer and a global retail deployment. Treat the low end as a viewer and the high end as a platform.
For the subscription route, published pricing is less uniform than the category’s reputation suggests. Vectary publishes two paid plans, Starter at $25 a month and Team at $250 a month, and lists app-free AR and an unbranded viewer only on its Business plan, which is quoted rather than published — and for an agency, the unbranded viewer is the entire point. Zakeke’s Shopify listing opens at US$69.90 per month for ten published products — with a “Powered by Zakeke” label on the viewer and a 1.9% transaction fee; removing the label starts at $129.90 with a 1.7% fee.
That transaction fee is the line to read twice. A percentage of your client’s sales, indefinitely, for a viewer, is a different commercial shape from a build — and it is the shape you will be asked to defend at renewal.
The numbers you will be asked for, and the one to stop repeating
Someone in the room will cite the 94% figure — that products with 3D or AR content convert 94% better than those without. It is worth knowing where it comes from: a Shopify post on X, dated September 2020. It is six years old, it was never published as a study, and essentially every secondary citation traces back to that one post. Using it is not dishonest, but presenting it as current research is, and a sharp client will find the source faster than you can defend it.
There is better material available. Shopify’s published case study on Gunner Kennels reports a 40% increase in order conversion rate, a 3% increase in cart conversion rate and a 5% reduction in return rate after introducing 3D and AR. That is one merchant, in one category, and it should be presented as exactly that — but it is a named, traceable, checkable result, which is more than the category usually offers.
The returns number is the one industrial and equipment buyers care about most, and it is the least well evidenced across the whole market. If a vendor quotes you a returns reduction, ask whose store it came from.
Five questions before anyone signs
- Which files do we receive? GLB and USDZ, or a login?
- Where do the models live? Your infrastructure, or the vendor’s?
- What stops working when we stop paying? If the answer is “the viewer”, that is a rental.
- Is the viewer branded, and can we remove the branding? On which tier, at what price?
- Is there a transaction fee? A percentage of sales is not a software cost.
Those five questions sort the market faster than any feature comparison, and they are the questions an agency should be asking on the client’s behalf — because the agency is the one who has to explain the renewal.
At TAPQUAD we build browser-based 3D showrooms, configurators and AR for agencies to ship under their own brand, and the 3D models we produce for a project are handed over in GLB and USDZ. That is not a differentiator so much as an admission of how this technology works: two formats, because the phones require two formats. Anyone telling you otherwise has not tested on the other phone.
Written for agency teams scoping AR for a client. If you want the equivalent argument about who owns the models at the end, that is a separate piece.