The short version: There are three routes to a WebAR Shopify integration, and most shops pick the wrong one. Shopify's built-in 3D media is free, needs no app, and handles the AR button for you — that covers the majority of stores. Embedding Google's <model-viewer> yourself buys you control over the viewer's look and behaviour, which matters if AR is core to your brand. Paid apps mainly sell you the 3D models and a dashboard, not the AR itself. Whichever route you take, the actual cost and the actual work is producing the 3D assets — the integration is the easy part.

What "WebAR on Shopify" actually means

People say WebAR Shopify integration to mean two quite different things, and conflating them is where most of the confusion starts.

The first is a 3D viewer — a model of your product sitting in a box on the product page that a shopper can spin with a finger. It runs in the browser on any device. No camera involved.

The second is AR placement — tapping a button and seeing that product at real scale on your own floor, through your phone camera. On an iPhone this hands off to Apple's AR Quick Look and needs a USDZ file. On Android it hands off to Google's Scene Viewer and needs a GLB. Some browsers can also do it inline through the WebXR APIs without leaving the page.

You almost always want both, and the good news is that both come from the same source asset. Get the 3D model right and every route below can consume it.

GLB

The binary glTF format. One file containing geometry, materials and textures. This is what Android and every web viewer wants.

USDZ

Apple's format, required for AR Quick Look on iPhone and iPad. Shopify generates this for you from a GLB.

WebXR

The browser API for inline AR. Support is patchy — treat it as a bonus, not the foundation.

Route 1: Shopify's native 3D media

Shopify has supported 3D models as a product media type for years, and it is the option most merchants overlook because it does not announce itself. You upload a GLB in exactly the same place you upload photographs. Shopify does the rest.

Per Shopify's own documentation, the platform accepts GLB and USDZ files up to 500 MB, automatically optimises anything over 15 MB, and generates whichever of the two formats you did not upload so that both iOS and Android are covered. You upload once; the correct file is served to each device.

500MB maximum file size Shopify accepts
15MB — above this, files are auto-optimised
2formats generated from your single upload
0apps required, and no monthly fee

If your theme is a reasonably current Online Store 2.0 theme, the 3D model appears in the product gallery next to your images and the AR button shows up by itself on supported phones. There is genuinely nothing to install.

Where it stops being enough: you get Shopify's viewer, with Shopify's controls, in Shopify's gallery. You cannot easily change the lighting environment, add hotspots that annotate parts of the product, put the viewer in a different part of the page, or fire your own analytics events when someone opens AR. For a homeware shop wanting customers to see a lamp on their sideboard, none of that matters. For a brand where the 3D experience is the pitch, it will.

Route 2: Embedding model-viewer yourself

<model-viewer> is an open-source web component maintained by Google and released under the Apache 2.0 licence. It is a custom HTML element: you load one script, then write a tag with a src pointing at your GLB and an ios-src pointing at your USDZ. It renders the 3D viewer, and its ar attribute produces the AR button that hands off to Quick Look or Scene Viewer.

It is, as far as we can tell, what most of the paid apps are running under the bonnet anyway.

The reason to do this yourself is control. You can set your own lighting environment so a matte ceramic reads as matte rather than plastic. You can pin annotation hotspots to specific parts of a model — the stitching on a bag, the port layout on a device. You can place the viewer anywhere in your Liquid template rather than only in the gallery. And you can attach your own event listeners, which is the only way to answer the question your finance director will eventually ask: did any of this sell anything?

Worth knowing before you commit: model-viewer's documentation states it targets recent versions of the major evergreen browsers and the last two Safari releases on macOS and iOS. That covers the overwhelming majority of real shopping traffic, but it is a genuine constraint rather than universal support, and it is your responsibility to handle rather than Shopify's.

The cost here is maintenance. You now own a script tag, a version number and a rendering surface that Shopify will not support if it breaks. That is a perfectly reasonable trade if AR is strategically important to you. It is a bad trade if you just want a spinning trainer.

Route 3: Third-party AR apps

Search for this topic and nearly every result is an app vendor. That is not a conspiracy, it is just who has an incentive to write about it. But it does mean the trade-offs get presented oddly, so here is the honest framing.

What you are actually buying from most AR apps is one or more of three things:

1
3D model production. Many apps bundle asset creation — you send photographs or a physical sample, they send back a GLB. This is the genuinely valuable bit, and it is a service, not software.
2
A management dashboard. Bulk-assigning models to variants, versioning, previewing across devices. Real value if you have hundreds of SKUs; near-zero value if you have twelve.
3
Analytics and extras. AR session tracking, QR codes for in-store use, occasionally virtual try-on for categories like eyewear that need face tracking rather than surface placement.

What you are usually not buying is AR capability that Shopify does not already give you. If a vendor's pitch is "add AR to your store", check whether their demo does anything the native 3D media type does not. Frequently it does not.

The one category where an app is clearly the right answer is face-tracked try-on — glasses, cosmetics, jewellery worn on the body. That is a materially different technology from placing an object on the floor, and building it yourself is not a sensible use of anyone's budget.

Side-by-side: which route fits which shop

 Native Shopify 3DSelf-hosted model-viewerThird-party app
Platform costNoneNone (Apache 2.0)Monthly subscription
Dev workNoneTheme edit + ongoing upkeepInstall; some theme work
Viewer controlMinimalFullVendor-defined
Custom analyticsNoYesVendor's dashboard
Face-tracked try-onNoNoSome vendors
Supplies the 3D modelsNoNoOften yes
Best forMost stores, most of the timeAR-led brands, bespoke PDPsLarge catalogues; try-on categories
A reasonable default: start native. It costs nothing and takes an afternoon. If, after a quarter, you can point at behaviour that native cannot support — you want hotspots, you want the viewer above the fold, you want AR opens in your own analytics — then move to model-viewer with the same GLB files you already made. Nothing is wasted.

The part nobody puts in the sales page

Every route above assumes you have a 3D model. You almost certainly do not.

This is the whole ballgame. The integration decision — the thing most articles spend two thousand words on — is a few hours of work. Producing accurate, well-lit, correctly-scaled 3D models of your catalogue is the actual project, the actual budget line, and the actual reason most AR rollouts stall after four SKUs.

Model production broadly happens three ways: photogrammetry (photograph a physical sample from every angle and reconstruct it), manual modelling from CAD or technical drawings, or AI image-to-3D generation. They differ enormously in accuracy, cost and how much cleanup they need afterwards, and picking wrongly for your product category wastes more money than any app subscription ever will.

We have written that up separately, because it deserves its own guide rather than a paragraph: what 3D product models cost and how to specify them.

File specs that actually matter

Here is where this guide diverges sharply from most of what you will read, so it is worth being precise about sources.

A correction worth making. A great many articles state that Shopify enforces a polygon limit — commonly "under 100,000 polygons". We could not find that figure in Shopify's documentation, and Shopify's own 3D modelling checklist does not state a polygon ceiling at all. It says to keep geometry as low as possible while retaining detail, and to respect the polycount limits of whichever media format you are targeting. Treat any specific poly number you see quoted as that author's rule of thumb, not a platform rule.

What Shopify's guidance does state, and what you should design to:

SpecShopify's stated guidanceWhy it matters
Target file sizeAround 4 MBThis is the number to design to. Mobile shoppers on cellular abandon slow-loading media.
Hard file limit500 MBEffectively irrelevant — if you are near this, something has gone wrong upstream.
Auto-optimisationAbove 15 MBShopify will compress it, but on its terms. Better to control quality yourself.
Texture resolutionNo larger than 2048×2048 px for mobile webTexture data usually dominates file size, not geometry.
Geometry styleQuads preferred unless the format requires trianglesCleaner deformation and easier edits later.

The practical read: your file size problem is nearly always textures, not polygons. A model that ships four 4K texture maps will be enormous regardless of how clean the mesh is. Halving texture resolution typically quarters that portion of the payload, and on a product that occupies a third of a phone screen, nobody will see the difference.

Roughly where the weight sits in a typical product GLB

Texture maps — usually the dominant cost

Mesh geometry

Materials, scene data, metadata

Indicative proportions for a typical retail product asset, not measured averages — the split varies enormously by product type. Inspect your own file before optimising; a scanned fabric sofa and a machined aluminium bracket sit at opposite ends of this.

How to check it genuinely works

"It looks fine on my laptop" is not a test. AR fails on devices, not desktops. Run these before you tell anyone it is live.

1
Open the product page on a real iPhone. Not the simulator, not a Mac. Confirm the AR button appears and that tapping it launches Quick Look rather than downloading a file.
2
Repeat on a real Android handset. Scene Viewer behaves differently and is the more common source of "it works for me" bug reports.
3
Check the scale. Place the object on your actual floor and measure it. Wrong-scale models are the single most common defect and the most damaging — a chair that appears doll-sized destroys the trust the feature was meant to build.
4
Throttle your connection. Load the page on a simulated 4G profile in DevTools and time the model. If it is still spinning after a few seconds, go back and cut your textures.
5
Confirm it does not wreck your Core Web Vitals. A 3D model that blocks or competes with your hero image will move your Largest Contentful Paint the wrong way. Lazy-load the viewer; never let it preload above your main product image.

Five ways this goes wrong

Scale drift

The model was built in centimetres and exported assuming metres. Everything looks right on screen and absurd in AR. Always verify against a real measurement.

Textures that dwarf the page

A 40 MB asset on a product page is a bounce, not a feature. Design to roughly 4 MB and treat that as a hard budget.

Four SKUs and a stall

The pilot goes live, nobody budgeted for the remaining 300 models, and the feature quietly becomes an inconsistency shoppers notice.

Open geometry

Non-manifold meshes, holes and duplicate vertices render acceptably in a viewer and glitch badly when AR tries to light and anchor them.

No measurement

AR ships, nobody instruments it, and twelve months later there is no evidence either way when someone asks whether to keep paying for it.

Variant mismatch

One model for a product sold in six colourways. Shoppers select navy and see the grey one. Either model each variant or do not offer 3D on that product.

Frequently asked questions

Do I need an app to add AR to a Shopify product page?

No. Shopify supports 3D models as a native product media type. You upload a GLB or USDZ file in the same place you upload product photographs, and Shopify generates the other format and serves the correct one to each device. The AR button appears automatically on supported phones with a current Online Store 2.0 theme. Apps become worthwhile when you need bulk catalogue management, face-tracked try-on, or when the vendor is producing your 3D models as a service.

What file format does Shopify need for AR?

GLB or USDZ. Shopify's documentation states both are accepted, at up to 500 MB, with automatic optimisation applied to files over 15 MB. In practice you upload a single GLB and Shopify produces the USDZ needed for AR Quick Look on iPhone and iPad, so you only need to manage one source asset.

Is there a polygon limit for Shopify 3D models?

Shopify does not publish a specific polygon ceiling. Its 3D modelling checklist advises keeping geometry as low as possible while retaining necessary detail and conforming to the polycount limits of the target media format, but it states no absolute number. The figures widely quoted online are individual authors' rules of thumb rather than platform rules. The constraints Shopify does state numerically are a target file size of around 4 MB and textures no larger than 2048 by 2048 pixels for mobile web.

What is model-viewer and is it free?

It is an open-source web component maintained by Google and released under the Apache 2.0 licence, so it is free to use commercially. You add one script and one HTML tag to display a 3D model and offer an AR button that hands off to AR Quick Look on iOS and Scene Viewer on Android. It gives you control over lighting, camera behaviour, annotation hotspots, placement in the page and custom analytics events — at the cost of maintaining it yourself.

Will 3D models slow my Shopify store down?

They can, if you let them. A 3D asset is typically far heavier than a product photograph, and an unoptimised one competing with your hero image will damage your Largest Contentful Paint. Design to roughly 4 MB per model, keep textures at or below 2048 by 2048 pixels, lazy-load the viewer so it never preloads ahead of your main product image, and test on a throttled mobile connection rather than office wifi.

Does AR on a product page actually increase sales?

Published figures vary widely and most circulating statistics originate from vendors selling AR rather than from independent studies, so we would not quote one as fact — we traced a set of those claims in our audit of virtual try-on returns data, and several did not survive checking. What we can say is that the only way to know for your catalogue is to instrument it: track AR opens as an event, segment sessions that opened AR against those that did not, and watch conversion and return rates on the specific SKUs where AR is live. That requires either self-hosted model-viewer or an app with genuine analytics, which is a real argument against the native route if measurement matters to you.

Want the models, not just the integration?

We build WebAR for UK retailers end to end — 3D asset production, Shopify integration, and the measurement layer that tells you whether it earned its keep. If you already have models and just need them live properly, that is a smaller and cheaper conversation, and we will say so.

Talk to us about your catalogue

Related reading: our WebAR development service, Shopify development, AR product visualisation, AR product viewers versus static photography, and whether virtual try-on really reduces returns.