Web AR Product Visualization: A Readiness Checklist

Web AR product visualization lets a shopper tap "View in your space" on a product page and see the item in their room through their phone camera, without installing an app. For the right products it answers the question photos cannot: how big is it really, and will it look right here. For the wrong products it is an expensive button nobody presses. This checklist helps you tell which side you are on, and what to prepare if the answer is yes.

How web AR works in a browser today

There is no single AR system across phones, so web AR is built on what each platform provides:

• iPhone and iPad: Apple's AR Quick Look. Apple's documentation shows how a website can link to a 3D file so tapping it opens the AR viewer. WebKit introduced this in Safari on iOS 12 in 2018: the link uses rel="ar", contains a single image, points to a USDZ file, and Safari marks it with a small 3D cube badge.
• Android: Google's Scene Viewer, or WebXR in supported browsers.
• One component for both: Google's open-source model-viewer web component handles the routing. Its documentation lists three AR modes, webxr, scene-viewer and quick-look, tried in that order by default. You supply a GLB model, and for iOS either a USDZ file through the ios-src attribute or nothing, in which case model-viewer generates a USDZ on the fly when the AR button is pressed. The documentation warns that the generated file is imperfect, for instance animations are not supported, so supplying your own USDZ can give better results.

In practice that means one 3D model, prepared well, can serve the product page's 3D viewer and AR on both major phone platforms. If you already have or plan a 3D product configurator, the same assets often carry over.

Is web AR product visualization a fit for your product?

AR earns its cost when size, placement or appearance in a real space affects the purchase. Score your product honestly:

• Size uncertainty: furniture, lighting, appliances, wall art, planters, large equipment. Strong fit.
• Placement matters: things that sit on a floor or hang on a wall. model-viewer's ar-placement attribute supports both floor and wall placement.
• Appearance in context: finishes and colors that look different under home lighting. Moderate fit.
• Small, familiar, low-cost items: cotton buds, cleaning supplies, refills. Weak fit. Nobody needs to see a box of cotton buds on their bathroom shelf before buying it; better photography and listing images do more.
• B2B packaging and print: useful for showing a box design on a shelf at true size during sales calls, even if it is not on a public product page.

If your products score weak, stop here. A strong product page without AR beats a weak one with it.

Model readiness checklist

The model is the product in AR, so its quality decides whether the feature builds trust or breaks it:

• True dimensions. Model from the spec sheet, in real units, and verify against a physical sample. A sofa that appears 10% too small is worse than no AR.
• Locked scale. model-viewer's ar-scale attribute can be set to "fixed," which keeps the model at 100% scale. For size-driven purchases, use it, so shoppers cannot accidentally pinch it smaller.
• Accurate materials. Color, gloss and texture checked on a phone next to the real product, under daylight and indoor light.
• Both formats. GLB for Android and the web viewer; USDZ for iPhone, generated or exported and then tested.
• Light files. Phones download these on mobile data. Simplify geometry and compress textures until the model loads quickly without visible loss.
• One model per variant that changes shape or size; color-only variants can often share geometry.
• Device testing on at least one recent and one older iPhone and Android phone before launch.

Page readiness checklist

The AR button sits inside a product page, and the page has to support it:

• Show the button only where it works. model-viewer exposes a canActivateAR property that is true when the current platform supports AR. Hide or change the button on desktop and offer a 3D viewer or a "send to phone" QR code instead.
• Clear label. "View in your room" is better than a generic AR icon on its own.
• Poster image while the model loads, so the page never shows an empty box.
• Accessible alternative. Alt text on the viewer, and dimensions stated in text near the button for anyone who cannot use AR.
• Placement on the page: near the main images and the size information, where the size question comes up.

Measure whether it helps

Set up tracking before launch so you can judge it on data:

• AR button taps as a share of product page views on mobile.
• Session outcomes. model-viewer's ar-status attribute reports the states not-presenting, session-started, object-placed and failed. The documentation says the full set is only reported for WebXR sessions, while failed fires whenever AR was started and none of the modes could launch. A high failure rate points to device or model problems.
• Conversion and returns for AR users compared with mobile visitors who did not use it, on the same products and period.
• Customer questions about size in chat and reviews, before and after.

If taps are low, check button placement and label before blaming the feature. If taps are high but conversion is flat, the model may be inaccurate or slow.

Common mistakes

• Launching AR across the whole catalog instead of the five products where size matters most.
• Using a decorative model built for renders, not a dimensionally accurate one.
• Never testing on iPhone because the team works on Android, or the other way round.
• Leaving the AR button visible on desktop, where it cannot work.

How we build it

At Pinn.Media we build the product imagery, 3D models and product pages together, so the photos, the 3D viewer and the AR all show the same product at the same size. One Amazon product launch we handled is an example of building a product's visuals as one system, from packaging to listing images. If you want to know whether AR is worth it for your range, book a discovery call at /contact#book.