Safari's <model> element: what your USDZ needs

What shipped

WebKit's Safari 27 beta post states it plainly: "The <model> HTML element is now available in Safari on iOS, iPadOS, and macOS, joining its existing availability in visionOS." Before this, <model> was a visionOS-only curiosity. Now it is a mainstream Apple-platform feature.

The framing Apple uses matters as much as the feature: <model> renders the same USDZ files that work with AR Quick Look today. There is no new format, no new export path, no separate build. Your existing USDZ pipeline is the pipeline. Which is excellent news, and also means the failure modes are inherited wholesale.

The markup

<model style="width: 480px; height: 480px">
  <source src="/models/chair.usdz" type="model/vnd.usdz+zip">
</model>

The <source type> and the file extension both matter. Content negotiation is on model/vnd.usdz+zip — the same IANA-registered MIME type AR Quick Look has always required — so a file served as application/octet-stream, or one that is not actually a .usdz, will not be picked up. Safari 27 beta also added dynamic-range-limit on <model>, giving you control over the HDR rendering range for 3D content.

What the USDZ itself must satisfy

Because <model> consumes the AR Quick Look asset, readiness is the union of USDZ packaging conformance and the Quick Look render constraints. These are the ones that stop the element rendering anything at all:

• A readable zip archive. <model> loads the file as a USDZ package; a corrupt archive shows nothing.
• A default stage as the first entry. The USDZ spec requires the first file in the package to be a native USD file. Without it there is nothing to render.
• Stored, uncompressed entries. USDZ requires zero compression; a deflated entry violates the packaging spec.
• 64-byte alignment. Each entry's data must begin on a 64-byte boundary so the package can be memory-mapped.
• A `.usdz` extension and the right MIME type. This is how <source type="model/vnd.usdz+zip"> negotiates.
• Every referenced texture bundled inside. A stage referencing a texture that is not in the archive renders black or wrong — USDZ is a self-contained bundle.
• Actual mesh geometry. A stage with no mesh renders an empty model. Failed conversions produce these more often than you would think.

The things that load but look wrong

1. Scale. Safari 27 explicitly "fixed <model> elements displaying at 100x the expected size for assets authored in tools that use centimeter units". The fix is real, but the safest asset still declares metersPerUnit = 1 or bakes the unit scale into the geometry — you cannot assume every visitor is on 27.
2. Orientation. Quick Look and Reality Composer assume Y-up. A Z-up stage lands sideways. Apple does not document this as a hard requirement, so treat it as strong practice rather than gospel.
3. Size and memory. <model> inherits Quick Look's memory behaviour, where "too large to open" is driven by decoded texture and geometry footprint rather than file size. Large files slow first paint and can fail outright on low-memory devices.
4. Texture encodings. 16-bit and paletted PNGs, and progressive JPEGs, are the recurring troublemakers. 8-bit truecolour PNG and baseline JPEG are the safe set.
5. Materials the source glTF had and USDZ does not. If your USDZ was converted from a glTF using transmission, volume, sheen, clearcoat, iridescence or anisotropy, the <model> render will differ from your web GLB render. See why converters break PBR.

What this changes for commerce

Until now, a broken USDZ cost you the AR button — an optional, secondary experience most shoppers never tapped. With <model>, the same file is the primary visual on the page for every Safari visitor on an Apple device. A dangling texture reference used to be a footnote; now it is your hero image rendering black.

The practical consequence is that USDZ deserves the same pre-publish rigour as your GLB, not less. Everything in the first list above is checkable from the bytes without a device, which is exactly the kind of check that belongs in CI rather than in a designer's manual review.

The honesty boundary

Nobody can promise you a Safari-accurate preview offline. Apple exposes no headless <model> or RealityKit renderer, so every tool in this space — ours included — is checking structural and documented-constraint conformance, not producing the render Safari will produce. A clean verdict means the bytes satisfy every documented requirement checkable from the file. For a hero SKU, still open it on a device.

If you are shipping to both platforms, the Android side of the story is in AR Quick Look vs Scene Viewer, and the packaging failure taxonomy is in USDZ not working in Quick Look.