When it comes to glb vs usdz, if you sell physical products online and want customers to view them in AR, you will quickly meet two file formats: GLB and USDZ. Shopify asks for 3D models. Your AR developer mentions USDZ for iPhones. Your WooCommerce plugin wants something else. Get the format wrong and your beautiful 3D product either will not load, looks broken, or only works on half your customers' phones.

This guide explains what GLB and USDZ actually are, how they differ, which one to use for Shopify and WooCommerce AR, and the practical implementation details that save you from the common pitfalls. No hype, just the technical grounding you need to brief a developer or evaluate an agency.

What GLB Is – Glb Vs Usdz

GLB is the binary container format for glTF (GL Transmission Format), maintained by the Khronos Group — the same consortium behind WebGL and Vulkan. Think of glTF as "the JPEG of 3D": an open, royalty-free standard designed for efficient transmission and loading of 3D scenes on the web.

A GLB file packages the 3D mesh, materials, textures, and animations into a single binary file. Key characteristics:

  • Open standard: no licensing fees, broad tooling support (Blender, Maya, 3ds Max, and most 3D pipelines export it).
  • Web-native: the format of choice for WebAR, Three.js, Babylon.js and web-based 3D viewers. Loads fast, streams efficiently.
  • Android's AR format: Google's Scene Viewer — which powers "View in your space" on Android — consumes GLB (technically glTF) files.
  • Physically-based materials: PBR material model means models look consistent across viewers that implement the spec.

What USDZ Is

USDZ is Apple's AR format, built on Pixar's Universal Scene Description (USD) technology. Apple introduced it alongside ARKit, and it is the format behind AR Quick Look — the "view in your space" experience on iPhones and iPads.

Key characteristics:

  • Apple ecosystem: USDZ is the native AR format for iOS/iPadOS. AR Quick Look launches directly from Safari with no app.
  • Single-file archive: like GLB, it bundles geometry, materials and textures into one file (uncompressed zip-based package).
  • Apple tooling: Apple's Reality Converter (macOS) converts common 3D formats to USDZ; Reality Composer lets non-developers build simple AR scenes.
  • More restrictive: AR Quick Look supports a narrower feature set than full glTF — certain material effects and animations that work in GLB viewers may not translate to USDZ.

GLB vs USDZ: Head-to-Head

Platform support

This is the deciding factor for most retailers. iPhones (Safari + AR Quick Look) want USDZ. Android (Chrome + Scene Viewer) wants GLB. There is no single format that natively drives AR on both — which is why the standard practice is to produce and serve both, letting the platform pick the right one. Any AR setup that only serves one format is silently excluding roughly half of mobile shoppers.

Web and viewer support

GLB wins for anything web-based: product configurators, 3D viewers embedded on product pages, and WebAR frameworks all speak glTF natively. USDZ is primarily an Apple AR-delivery format rather than a general web 3D format — you would not build a web 3D viewer around USDZ.

Features and fidelity

glTF/GLB supports a richer feature set: advanced PBR materials, clearcoat, transmission, and fuller animation support. USDZ via AR Quick Look covers the essentials well (geometry, standard materials, basic animations) but lags on exotic material effects. In practice, for product visualisation — a chair, a trainer, a lamp — both formats reproduce what matters. Problems arise mainly with highly reflective or transmissive materials (chrome, glass), where you should test on both platforms.

File size and performance

Both formats are designed for efficient delivery, and with proper optimisation (texture compression, polygon budgets, Draco mesh compression for GLB) either can load quickly on mobile networks. USDZ files tend to run larger because the format is zip-based without mesh compression equivalent to Draco — another reason to keep polygon counts disciplined regardless of format.

Tooling and pipeline

GLB enjoys broader DCC (digital content creation) support — Blender exports excellent glTF natively, and most pipelines target it first. USDZ conversion typically happens as a final step via Reality Converter or command-line tools like usdzconvert. A sane production pipeline models and validates in GLB, then converts to USDZ for Apple delivery.

Which Format for Shopify AR?

Shopify's 3D/AR product feature accepts 3D model uploads and handles the platform split for you: it serves the appropriate format to each device so iPhone shoppers get AR Quick Look and Android shoppers get Scene Viewer. In practice, you upload your model files and Shopify's pipeline manages delivery.

What this means for you:

  • Supply both GLB and USDZ versions of each product model where possible, so neither platform falls back to a degraded experience.
  • Validate scale obsessively — a 1.8-metre sofa that appears 18 centimetres long in AR destroys trust instantly. Model in real-world units (metres) from the start.
  • Keep textures colour-accurate. Shopify shoppers compare the AR view against your product photography; mismatched colours generate returns, not sales.
  • Respect Shopify's file size guidance — oversized models load slowly on mobile data and hurt the experience you are paying to create.

Which Format for WooCommerce AR?

WooCommerce has no single native AR pipeline comparable to Shopify's — AR comes via plugins and custom builds, which means more flexibility and more decisions. The established pattern:

  • WebAR product viewers (the most common WooCommerce route) use GLB via Three.js or Babylon.js, working across devices in the browser.
  • Platform-specific AR (AR Quick Look on iOS, Scene Viewer on Android) needs both USDZ and GLB, typically wired through model-viewer web components or plugin shortcodes that select the right file per device.
  • Because you control the stack, you can also add configurators, variant switching and analytics more freely than on Shopify — at the cost of owning the implementation.

If your WooCommerce AR plugin only handles one format, that is a limitation worth knowing about before you commit to modelling dozens of products.

Implementation Tips That Prevent Pain

Model once, convert, don't remodel

Build your master asset as a clean, well-structured GLB, then convert to USDZ. Maintaining two separate modelling pipelines doubles cost and guarantees the versions drift apart. Conversion tooling is mature — use it.

Set a polygon and texture budget

Agree limits with your 3D artist upfront: polygon counts appropriate to the product's on-screen size, texture resolutions that survive mobile GPUs, and compressed textures. A product viewed at 15cm on a phone screen does not need film-quality geometry — it needs fast loading.

Test on real devices, both platforms

Emulators and desktop previews lie. Check every hero product on a recent iPhone and a mid-range Android phone, on both Wi-Fi and mobile data. Pay attention to scale, material appearance under AR lighting, and load time. This testing pass catches the majority of real-world failures.

Handle the no-AR fallback gracefully

Older devices, desktop browsers and in-app webviews may not support AR. The 3D model should still render as an interactive viewer (rotate/zoom) in those cases — a customer who cannot place the sofa in their room can still inspect it in 3D. Never show a dead button.

Keep models under version control

Products change — new colourways, revised dimensions, updated packaging. Treat 3D models like product photography: versioned, named consistently, and updated through the same content workflow. A stale 3D model showing last season's design is worse than no model.

Common Mistakes

  • Serving only one format and unknowingly cutting off half of mobile shoppers.
  • Wrong scale — the single most common and most damaging error in retail AR.
  • Uncompressed 20MB models that take an age to load on mobile data.
  • Materials that don't survive conversion — test chrome, glass and emissive materials on both platforms.
  • No fallback for devices without AR support.
  • Treating 3D as one-off content instead of maintaining it alongside photography.

A Simple Decision Framework

If the detail above is blurring, here is the short version for decision-makers:

  • Shopify store? Supply GLB + USDZ per product, model at real-world scale, and let Shopify handle per-device delivery. Your job is asset quality, not pipeline engineering.
  • WooCommerce store? Default to a GLB-based WebAR viewer for cross-device coverage, and add USDZ + AR Quick Look support if iPhone traffic justifies it. Budget for owning the implementation.
  • Custom web experience or configurator? Build on GLB with Three.js or Babylon.js — it is the web-native choice with the deepest tooling.
  • Only one format possible? Choose based on your traffic split, but understand you are accepting a degraded experience for the other half of mobile users. Revisit as soon as budget allows.

In every case, the non-negotiables are the same: real-world scale, colour accuracy, optimised file sizes, real-device testing on both platforms, and a graceful fallback where AR is unavailable. Formats are a solved problem; craft is where projects succeed or fail.

The Bottom Line

GLB is your web and Android format; USDZ is your iPhone format; serious retail AR serves both from a single GLB-mastered pipeline. The format decision is the easy part — the discipline is in scale accuracy, optimisation, cross-device testing and treating 3D models as living product content.

If you need 3D models built or an AR viewer implemented for your Shopify or WooCommerce store, get in touch. Our team produces 3D product visualisation, builds WebAR experiences and custom AR applications for UK ecommerce brands — and we will make sure your products look right on every device. Start with our 3D visualisation services.

For more information, see GOV.UK.

AR & WebAR Visuosofts Get a Quote