How to convert USDZ to STL
- Drop the .usdz fileThe workspace opens it as the ZIP archive it really is and looks for the root layer. If that layer is ASCII USD the scene builds; if it is a binary crate the read stops there with an unsupported-format message, because this reader parses text stages only.
- Check the preview and the triangle countMesh geometry is assembled into a scene graph with the transforms from the stage applied, and PNG textures found inside the archive are decoded so the on-screen model looks like the one you know. The reported facet count is your first clue about how heavy the geometry actually is, independent of file size.
- Select STL as the targetEvery mesh primitive is collected and transformed into world space, then expanded so each triangle becomes its own facet record. Materials, lights, cameras, animations and the node hierarchy have no representation in an STL and are dropped at this point rather than at the end.
- Convert and downloadThe exporter writes binary STL: an 80-byte header, a 32-bit facet count, then 50 bytes per triangle holding one normal vector, three duplicated vertices and an unused attribute word. All conversion work happens inside your browser tab; nothing is uploaded.
- Fix units and orientation in the slicerBefore slicing, set the scale from a dimension you know and rotate the part onto the build plate. The numbers come out of a USD stage in metres with Y up, and STL records neither, so this step is where an AR asset becomes a printable object.
What happens when USDZ is converted to STL
A USDZ is an ordinary ZIP with rules
Universal Scene Description packages a scene as a .usdz file by zipping a layer with its assets. The format requires deflate compression and forbids encryption, and its layout convention is that the first entry in the archive is the root layer, the stage an application opens. Textures sit alongside it and are referenced by name rather than by URL. That structure is what lets a browser read the whole thing in one pass: the file is inflated in memory, the entries are classified by extension, and only two kinds are acted upon — text layers are parsed and PNG images are turned into object URLs for preview.
Only the ASCII flavour of USD parses
USD stores a layer either as human-readable .usda text or as .usdc, a compact binary container called a crate whose first seven bytes spell PXR-USDC. Crates are the default output of most authoring tools because they are smaller and faster to load, and a Quick Look asset you downloaded is more likely to be one than a text stage. The reader here inspects that signature and skips crates outright, so a valid, uncorrupt USDZ can still fail to open. Unzip the file and look for the extension of its first entry before assuming something is wrong with your model. Where you control the export, choose the ASCII option; on a machine with the OpenUSD tools, usdcat can rewrite a layer as text.
Scene graph in, one triangle soup out
A stage describes a hierarchy: transform nodes carry translation, rotation and scale, mesh primitives sit underneath them, and materials bind to those primitives by relationship. Converting to STL means evaluating every mesh into world coordinates and concatenating the results, so a scene of twelve named objects becomes one unnamed shell with the placement baked in. Lights, cameras, shaders, skinning and animation have no counterpart in a facet record and disappear. Where parts overlap, the merged triangles intersect, and a slicer that insists on a single watertight volume may need to union or repair them.
Indexed meshes expand, because STL cannot share a vertex
USD mesh primitives are indexed: a positions array plus a topology array of indices, so a corner shared by four faces is stored once. Binary STL has no equivalent mechanism — each of its 50-byte records carries its own three complete vertices, and the format has no index table at all. Conversion therefore walks the index buffer and writes one facet per triangle, inflating vertex data by roughly the reuse factor rather than compacting it. No welding pass runs anywhere in the export path, so the facet count is simply the triangle count of the source scene. That is why the triangle count reported after loading, not the size of the USDZ on disk, predicts how heavy the downloaded STL will be.
Nothing converts metres to millimetres
USD is authored in metres by convention, and a stage can restate its scale with a metersPerUnit value so that downstream tools interpret the numbers correctly. STL stores twelve 32-bit floats per facet and declares nothing at all; the entire ecosystem reads those floats as millimetres. The conversion copies coordinates through unchanged and neither reads nor writes a unit, which is why an AR model straight to a slicer arrives at an absurd size in one direction or the other. Take a known feature — a wall thickness, a hole diameter — measure it after import and scale by the ratio.
Y-up authors, Z-up printers
The vertical axis is the other silent convention break. Interactive 3D and augmented reality place the camera above the XZ plane with Y pointing up, which is what a phone compositor expects. Stereolithography named the vertical axis Z, and every slicer since lays a part on the XY plane. Since the STL facet is just three coordinates with an orientation-free normal, no conversion step can be blamed for getting this wrong, and none is performed here either. A model that stood correctly in Quick Look usually needs a ninety-degree rotation about X before the slicer agrees.
USDZ vs STL
| USDZ source | Binary STL output | |
|---|---|---|
| Container | Deflate ZIP with a stage and assets | Flat record stream, no packaging |
| Layer encoding | ASCII .usda or binary .usdc crate | Not applicable |
| Geometry basis | Indexed meshes, subdivision, point clouds | Unshared planar triangles |
| Default unit | Metres, restatable by metersPerUnit | None; slicers assume millimetres |
| Up axis | Y by convention | Unspecified; Z by printing convention |
| Materials | PBR shading, RealityKit extensions, PNG textures | None; attribute word is zero |
| Scene structure | Xform hierarchy, named prims, relationships | Single merged triangle list |
| Animation | Sampleable attributes and time codes | Snapshot of one moment |
| Purpose | Real-time AR viewing | Slicer input |
Supported formats
| Format | Read | Write | Notes |
|---|---|---|---|
| STEP (.step .stp) | Yes | – | ISO 10303 B-rep, AP203 / AP214 / AP242 |
| IGES (.iges .igs) | Yes | – | Entity-based surfaces, up to 5.3 |
| BREP (.brep) | Yes | – | OpenCascade native B-rep |
| STL (.stl) | Yes | Yes | Binary and ASCII triangles, no units |
| OBJ (.obj) | Yes | Yes | v / vn / f records; .mtl references ignored |
| PLY (.ply) | Yes | Yes | Binary position and normal arrays |
| GLB / glTF (.glb .gltf) | Yes | Yes | glTF 2.0, binary or JSON with data URI |
| 3MF (.3mf) | Yes | Yes | OPC/ZIP package, declares millimetres |
| FBX (.fbx) | Yes | – | Binary and ASCII, static mesh only |
| DAE (.dae) | Yes | Yes | Collada scene graph is flattened |
| 3DS (.3ds) | Yes | – | Legacy chunk-based 3D Studio format |
| AMF (.amf) | Yes | – | XML, ZIP-compressed packages supported |
| USDZ (.usdz) | Yes | Yes | ZIP containing a USD stage |
Known limitations and why a conversion can fail
Binary crate stages are the dominant failure
This is the first thing to check and it accounts for most refusals. A USDZ whose root layer is a .usdc crate, or a .usd entry carrying the PXR-USDC signature, is well-formed but unreadable here: the archive opens, the crate is identified and skipped, and no scene remains to convert. The message you get is misleading, because it tells you the file “looks damaged or is not a real USDZ file” when nothing is wrong with the archive itself; the reader simply has no crate parser. The fix lives on the authoring side. Re-export choosing an ASCII stage where the tool offers one, or run the layer through usdcat to produce text and repack it as USDZ.
Only PNG textures are picked up
Inside the archive, texture entries are acted upon only when they are PNG. A USDZ referencing JPEG or other imagery yields a stage that still parses, with materials whose textures simply never load, so the preview appears untextured even though the file is fine. Geometry is unaffected and the STL is identical either way, since no texture information can be exported. This matters only if you are judging the conversion by the on-screen preview rather than the mesh.
Scale and orientation are never corrected for you
Because neither property is encoded in an STL, the converter cannot assert a preference for either: applying a metre-to-millimetre factor would silently corrupt a stage whose metersPerUnit already differed from one, and rotating every mesh would break workflows that place parts deliberately. Both therefore pass through untouched, and both have to be set in the slicer or a mesh editor. Expect to type a scale number and an X rotation after every AR-to-print conversion; that is the format boundary, not a defect.
AR meshes are frequently unprintable geometry
Assets made for Quick Look optimise appearance at arm's length rather than manufacturability. Single-sided surfaces with no wall thickness, decorative parts that intersect, hairline features below a nozzle diameter and scanned meshes with holes all look correct in AR and are meaningless to a slicer. The conversion faithfully reproduces them, so the resulting STL can export cleanly and still refuse to slice. Repair in a mesh tool, or convert onward to OBJ for editable text mesh, before blaming the export.
Huge ASCII stages exhaust tab memory
An ASCII USD layer states every vertex position and normal as text, so a dense mesh produces a stage several times larger than its crate equivalent, which has to be inflated from the ZIP and parsed as text inside a browser tab with a 32-bit WebAssembly address space. Very heavy AR scans can fail with a memory or script error before a triangle is written. Decimate the mesh in the authoring tool, or extract the mesh and convert a lighter source format.
Nothing leaves the device, but the page is not an app
The archive is read into the page and tessellation runs locally, so there is no upload endpoint, no queue and no retention. This is a web page rather than an installable offline application, though: it is fetched over the network, as are the WebAssembly modules behind some format readers, so the first conversion in a session needs connectivity.
Frequently asked questions
Can I convert on this page itself?
No. This page is the reference for the USDZ to STL path, and the conversion itself runs in the workspace that the button above opens, with both formats already selected. Your file is read in that browser tab and the download is written locally, so there is no upload stage in either place. Keeping the documentation and the engine on separate addresses lets file support and detail levels change behind one workspace without breaking the page you are reading.
My USDZ fails immediately. Why?
Most likely because it contains a binary crate layer, which is the common case for files produced by Xcode, Reality Composer and most AR Quick Look assets. A USDZ archive stores its root layer either as plain-text .usda or as a compact binary .usdc, and the reader here understands only the text form. Be aware that the failure is reported unhelpfully: the page says the file “looks damaged or is not a real USDZ file”, when in fact the archive opened fine and its stage was simply skipped as a crate. The file is not corrupt and your model is not lost; you need an ASCII version. Unzip the archive and check the first entry, then re-export choosing ASCII or .usda, or rewrite the layer with the OpenUSD usdcat tool.
How do I tell ASCII from binary without converting?
Unzip the file and look at what is inside. A USDZ is an ordinary deflate-compressed archive with no encryption, so any archiver can list it. If the first entry ends in .usda, or ends in .usd and opens as readable text beginning with a usda version line, the converter can parse it. If the first entry ends in .usdc, or a .usd entry begins with the seven-byte PXR-USDC signature, it is a binary crate and will not load. The extension alone is not decisive, because a .usd entry can be either flavour.
Why does my STL come out a thousand times too big or too small?
Because USD and STL disagree about units and nothing bridges them. A USD stage works in metres by convention and records its scale explicitly through a metersPerUnit value on the stage, while STL stores anonymous 32-bit floats and every slicer assumes millimetres. This pipeline writes the coordinates it read without applying that conversion, so a correctly authored AR cup arrives in the slicer as a 95-metre object, or one you pre-scaled for a game engine arrives as dust. Measure the bounding box on import and set the scale factor in the slicer; that is the only reliable step.
Does the model end up standing up the right way?
Often not, and this is a convention problem rather than a bug. USD scenes follow the graphics convention with Y as the up axis, which is what a phone expects when compositing an AR object onto a camera image. Additive manufacturing inherited Z-up from stereolithography machines, and slicers lay a model on the XY plane accordingly. No axis rotation is inserted during conversion, so a model that stood upright in Quick Look arrives lying on its front. Rotate it ninety degrees about X in the slicer, or in a mesh editor before slicing.
What happens to the textures and materials?
They are discarded on the way out. A USDZ carries physically based shading, typically authored for Apple's RealityKit renderer, referencing images inside the same archive. STL has no material block, no texture coordinate field and no colour channel; its facet record is twelve floats and a two-byte word that is written as zero. The PNG textures embedded in the archive are still decoded so the on-screen preview can look right before you export, but the downloaded STL is a single unshaded surface. If you need the appearance, keep the USDZ and convert to GLB instead.
Why is my multi-part AR model one solid object now?
Because STL cannot name anything. A USD stage may hold a hierarchy of Xform nodes, several mesh primitives, per-material splits and transform stacks; AR viewers rely on that to move or highlight pieces. Before serialisation every vertex is transformed into world space and the nodes are merged into one triangle list, so parts that were separate become one continuous skin. If the parts intersect, the merged shell is usually not manifold, and some slicers will want to repair it before they will slice.
Does the converter deduplicate shared vertices?
No, and the reason is that the format cannot express it. USD mesh primitives are indexed: a position array plus an index buffer, so a corner shared by four faces is stored once. A binary STL record carries its own three complete vertices, with no index table and no sharing mechanism anywhere in the file. Conversion walks the indices and writes one 50-byte facet per triangle, so the vertex data inflates by roughly the reuse factor instead of compacting. Nothing is deleted and no coordinate moves: the facet count equals the triangle count of the source scene, which is the number to watch when the download comes out larger than you expected.
Why does a small USDZ take longer than an STL of the same size?
Because a USDZ is a ZIP archive and its bytes are mostly imagery. A two-megabyte file can be a modest mesh next to two megabytes of PNG albedo and normal maps, and the reader has to inflate the archive and parse the ASCII scene description, which is verbose by design. On the other hand an ASCII stage with a dense scanned mesh can be enormous as text and still expand into a manageable triangle count. Neither the file size nor the download time tells you how heavy the geometry is.
Can I convert .usd or .usda files directly?
Yes for ASCII. The reader accepts .usda and also .usd provided the .usd file is a text stage rather than a crate, and .usda is listed among the site's input formats. What it will not accept is a binary crate in any wrapper, or a loose USD directory with textures referenced by relative path, since the archive is what makes those references resolvable in a browser. Pack it as USDZ or convert the mesh-only content first.
What is the sensible pipeline from an AR asset to a printed part?
Confirm the stage is ASCII, convert here to STL, then in the slicer set the unit scale from a known dimension on the model, rotate it onto its intended build plate, and let the slicer report holes and non-manifold edges. AR meshes are made to be looked at from a distance and often have single-sided surfaces, thin shells and intersecting decorative parts, all of which are invisible in Quick Look and fatal in a slicer. If the mesh needs genuine repair, converting it onward to OBJ gives you an editable text mesh that most repair tools accept.
References
- Apple Quick Look — USDZ
- three.js documentation — loaders and exporters
- How this site is built and tested
Related converters
All converters
Last updated: