Embed guide
Once you have a 3D model of a product, getting it onto a web page is a solved problem: Google's model-viewer web component handles the rendering, rotation, zoom, and AR handoff in a few lines of markup. The harder questions are where the GLB and USDZ files come from, who hosts and compresses them, and who keeps them working when the product changes. This guide covers both the DIY path and the managed path honestly.
Three things: a GLB file of the product (the standard format for web and Android AR), optionally a USDZ file of the same product for iPhone AR (Quick Look uses USDZ, not GLB), and Google's model-viewer web component to render them. Nothing else is required — model-viewer is a single script tag and a custom HTML element.
Load model-viewer with a script tag pointing at Google's CDN build, then add a model-viewer element to the page with a src attribute pointing at your GLB file, an ios-src attribute pointing at your USDZ file, the ar and camera-controls attributes to enable AR launch and drag-to-rotate, and a poster attribute pointing at a static image to show before the 3D file finishes loading. That's the whole embed: one script tag, one custom element, four or five attributes.
File size and compression: an uncompressed GLB straight out of most 3D tools can run 20-50 MB, which will stall on mobile; Draco geometry compression and compressed textures typically get furniture models down to a few megabytes without visible quality loss. Hosting and CORS: the GLB and USDZ files need to be served with correct CORS headers or model-viewer can silently fail to load them cross-origin. Poster images: without a poster, shoppers on a slow connection see a blank box while the model streams in, which reads as broken. True-to-scale dimensions: AR is only convincing if the model's real-world scale is correct — a sofa that renders at the wrong size undermines the entire point of showing it in AR, so the source geometry needs accurate width, height, and depth baked in before export.
On WordPress and WooCommerce, you can hand-write the model-viewer markup in a block or template, or use a plugin that wraps it for you — the Augmenta AR plugin, for example, adds a shortcode, a Gutenberg block, and an Elementor widget that embed a hosted viewer without you touching a GLB file directly. On Shopify, native 3D media support means you can upload a GLB directly to a product's Media field in the admin and Shopify renders it with its own model-viewer-based player on the product page, no app required. On any other platform, a plain iframe embed pointing at a page that itself contains the model-viewer markup works everywhere a script tag is allowed, which covers the vast majority of site builders.
Being fair to the DIY path: if you already have a GLB and a developer, embedding it yourself costs almost nothing. What a managed service like Augmenta actually adds is upstream of the embed: turning product photos into the 3D model in the first place (most furniture stores don't have a GLB to embed at all), producing both GLB and USDZ from the same source so iPhone AR works, compression tuned for furniture geometry and materials, CDN hosting so the files load fast globally, re-generating the model when a product's finish or dimensions change, and view/interaction analytics so you know which products are actually being rotated and AR-launched. None of that is required to embed a single file you already have — it's what's required to have a maintained catalog of correct, fast-loading 3D models in the first place.
If you already have 3D source files (or a way to produce them) and a developer who can maintain hosting, CORS, compression, and updates, the DIY model-viewer path is genuinely fine and costs nothing beyond hosting. If you only have product photos, no 3D team, and no appetite to rebuild the pipeline every time a SKU changes, a done-for-you service that delivers the finished GLB/USDZ pair plus hosting is the faster and more durable route. Many stores start with one hand-embedded hero product to learn the format, then move to a managed pipeline once they need it across a real catalog.
Live demo
FAQ
Either from a 3D artist or CAD source if one exists, from a self-serve image-to-3D tool if you're comfortable reviewing and fixing the output yourself, or from a managed service that generates and quality-checks the model from product photos for you, as Augmenta does.
Only if you want AR on iPhone. Apple's Quick Look AR viewer requires USDZ; it will not open a GLB. Android's Scene Viewer and desktop/mobile browsers work directly with GLB, so USDZ is strictly an iOS AR addition, not a replacement.
Not if it's set up correctly. Load the model lazily (only when it scrolls into view or on interaction), compress the GLB with Draco and compressed textures, and always show a poster image so the page has something to paint immediately. An unoptimized multi-tens-of-megabytes GLB loaded eagerly on every page view is what causes the slowdown people worry about, not 3D itself.
Yes to both. Shopify has native 3D model support in the product Media field, no app needed for basic display. WordPress/WooCommerce needs either hand-written model-viewer markup or a plugin — the Augmenta AR plugin adds a shortcode, Gutenberg block, and Elementor widget for exactly this.
Yes. model-viewer's ar attribute triggers each platform's built-in AR viewer directly from the browser: Quick Look on iPhone and Scene Viewer on Android. No app download is required on either platform.
One script tag loading model-viewer from a CDN, and one model-viewer element with a src pointing at your GLB, ios-src pointing at your USDZ, plus the ar and camera-controls attributes. That's a working, rotatable, AR-capable embed.
Show shoppers what the product looks like in their room, then track whether they return to your store.