What Are USDZ and glTF? 3D Formats for AR Explained

You have scoped an AR feature. A shopper points a phone at the floor, and your sofa appears at full size in their living room. Then your 3D artist asks the question that decides half the pipeline: which file format does the app ship? The answer people expect is one name. The real answer is two, plus a conversion step, and getting this wrong means the model works on an iPhone and shows nothing on Android, or the reverse.

This guide explains USDZ and glTF the way an engineer who has shipped AR would explain them to a founder. What each one is, why you almost always need both, what they support, how big the files should be, and how to convert between them. No hype, and every platform fact is linked to the official source.

What are USDZ and glTF?

USDZ and glTF are two file formats for 3D models used in augmented reality. glTF is the open standard managed by the Khronos Group and read by Android and the web. USDZ is Apple format, read by AR Quick Look on Apple devices. Both store the shape, the materials and the animation of a model, but each platform reads its own one.

Think of them like an image that needs to work everywhere. The picture is the same, but one device wants a PNG and another wants a HEIC. For 3D, Android wants glTF and Apple wants USDZ. The model is the same object. The wrapper is different.

glTF and GLB, the open standard

The Khronos Group, the body behind graphics standards like Vulkan and OpenGL, calls glTF an API neutral runtime asset delivery format that bridges 3D content tools and graphics applications. In plain terms, it is a format built for shipping models to a device and drawing them fast, rather than for editing them.

glTF comes in two packagings. A .gltf file is JSON text that references separate files for the geometry and the images. A .glb file packs the JSON, the binary geometry and the textures into a single file. GLB is the practical choice for AR because one file is easier to host, cache and move. The spec supports PBR materials, which stands for physically based rendering, the model of how light behaves on a surface, using its metallic roughness system, and it supports keyframe animation. Textures are stored as PNG or JPEG inside the file.

USDZ, the Apple format

USDZ is a single file package built on Universal Scene Description, or USD, the scene format Pixar created for film. The ".z" means it is a zip style archive holding the model and its textures together. Apple reads USDZ through AR Quick Look. Apple states that built in apps such as Safari, Messages, Mail, News and Notes use Quick Look to display USDZ files on iPhone, iPad and Apple Vision Pro. A shopper taps an AR badge on a web page and the object drops into their room, with no app install.

This is the reach that makes USDZ worth the extra work. A user on an iPhone can see your product in AR straight from Safari. That single fact often decides whether an AR feature is worth building at all, a point covered in WebAR versus a native AR app.

USDZ vs GLB: what is the difference?

The core difference is the platform, not the quality. GLB is the binary form of the open glTF standard, read by Android Scene Viewer and web viewers. USDZ is Apple own package, read by AR Quick Look on iOS, iPadOS and visionOS. Both hold geometry, PBR materials and animation. So the question is rarely "which is better", it is "which platforms do I need to reach".

For anything with real iPhone and Android traffic, the honest answer is both. Apple devices will not open a GLB in AR Quick Look, and Android Scene Viewer expects glTF or GLB. If you ship only one, half your users get a broken experience. The figure above lays the two families side by side so you can see there is no overlap in the native viewers.

Do you need both USDZ and glTF?

In most cases, yes. If your AR feature has to work on both iPhone and Android, or from a web link that either phone can open, you need a GLB for Android and the web and a USDZ for Apple. The good news is that you do not model twice. You author one clean source model, export a GLB, then convert that to USDZ, and compress both.

Here is the pipeline that most AR product teams end up with.

The web layer is where the two formats meet cleanly. Google model-viewer web component displays interactive 3D models on the web and in AR. On an Android phone it hands off to Scene Viewer using your GLB. On an iPhone it hands off to AR Quick Look using a separate USDZ file you supply alongside the GLB. One web tag, two files behind it, and the right one is chosen by the device. That is the cleanest way to serve both without writing platform code yourself.

What do glTF and USDZ actually support?

Both formats support the things a shopping AR app needs: solid geometry, PBR materials for realistic light, texture maps, and animation. The differences that matter in practice are in packaging, in how each one compresses, and in which viewer reads it. The table below is the version I hand to a client scoping their first AR build.

A note on the two AR viewers, because their rules bite in testing. Google requires that a model for Scene Viewer is served over HTTPS and uses a right handed coordinate system with the front of the model facing positive Z. Get the axis wrong and your chair faces the wall. On the Apple side, USDZ carries its lighting and materials in a way tuned for AR Quick Look, so a model that looks right in your 3D tool can look flat or wrong on an iPhone until you check it there. Test on both real devices, every time.

How big should an AR model be, and how do you get there?

Smaller than a game asset and smaller than most artists first deliver. An AR model downloads over a phone connection and renders on a mid range device while the camera is running, so weight hurts twice, once on load and once on frame rate. As a working target we keep a single AR product model in the low single digit megabytes, though the right number depends on the object and your audience devices.

Two compression tools do most of the work, and both plug into the glTF pipeline. Draco, from Google, compresses the 3D geometry, the mesh and its point data, so the file downloads faster with no visible quality loss. KTX2, from Khronos, using Basis Universal, compresses the textures into a form the GPU can use directly, which cuts both the download size and the memory the model uses on the device. Textures, not triangles, are usually what makes an AR file heavy, so KTX2 is often the bigger win.

This is where the 3D pipeline turns into real budget. Making one hero model look good is craft. Making a catalogue of them, each exported to GLB and USDZ, compressed, and checked on two platforms, is an operation. That work is broken down in how to make 3D models for an AR furniture app, and it is often the line item founders underestimate most.

How do you convert between glTF and USDZ?

You start from a GLB or glTF and produce a USDZ from it. For years the simple route was Apple Reality Converter, a Mac app that took .obj, .gltf and .usd files, showed the converted USDZ result, and let you adjust materials and preview under different lighting. Apple has since retired that app on current macOS, so teams now reach for other tools.

The working options today are:

• Command line USD tools. The open USD toolset includes utilities that build and package USDZ, which is what most automated pipelines call.
• glTF to USD converters. Scripts and libraries that read a GLB and write USD, then package it as USDZ. These fit into a build server so a new model produces both files automatically.
• Third party and native apps. Several maintained tools have stepped in where Reality Converter left off, wrapping the same USD engine in a modern app.
• 3D tool exporters. Some digital content tools export USDZ directly, though results vary and always need a device check.

One rule holds across all of them: conversion is not lossless in practice. A material, a texture setting or a complex animation rig can shift or drop in the move from glTF to USD. So the last step is never the converter. It is opening the USDZ on a real iPhone and the GLB on a real Android phone and comparing them to the source. Automate the conversion, but never automate away the human who looks at the result.

When one format is enough, and when this is not worth it

Both formats are not always the answer. Pick one, or none, in these cases.

• You only ship to one platform. An internal iPad tool for a showroom needs only USDZ. An Android only kiosk needs only GLB. Building the second file is wasted effort until you add the second platform.
• Your models change constantly. If your catalogue turns over weekly and every item needs a hand checked model in two formats, the content operation can cost more than the app. Sometimes the honest call is fewer AR products, done well, rather than a whole catalogue done thinly.
• The object does not need real scale or depth. If a 360 spin or a good set of photos answers the shopper question, AR adds cost without adding much. AR earns its place for large or spatial items, a sofa, a wardrobe, a bike, not a phone case.
• Your audience devices are old or low end. AR Quick Look and Scene Viewer both need reasonably modern hardware. If a large share of your users are on older phones, plan a clean non AR fallback first, and treat AR as the bonus.

There is also a hardware line worth knowing before you commit, since some AR features lean on depth sensors that not every phone has. We cover that in whether you need LiDAR for an AR furniture app, and the related question of how to get accurate AR measurements. The format is only one layer of the stack; the SDK underneath it, ARKit on iOS and ARCore on Android, is another decision covered in ARKit versus ARCore for AR apps.

What this means for cost and scope

Formats sound like a small technical detail. In a real build they set the shape of two budget lines: the app work, and the 3D content operation that feeds it. The app has to detect the platform and serve the right file, which is well trodden ground. The content side, authoring, dual export, compression and per device checking, scales with the size of your catalogue and is the part that surprises people.

Appico builds mobile apps under a fixed scope with transparent pricing, and our published starting point for a mobile app is from $12,000, with larger builds scaling up to around $150,000 depending on features and content volume. AR sits at the higher end because of that content pipeline, not because the format handling is hard. If you are still shaping the idea, turning an idea into an app walks through the earlier steps, and you can size a build with our app cost calculator. For an AR retail example in the same family, see the cost and time to develop a virtual try on fashion app.

Our take

Stop looking for the one true AR format. There is not one, and the search wastes weeks. The pattern that works is boring and reliable: author a clean model once, export GLB for Android and the web, convert to USDZ for Apple, compress both with Draco and KTX2, and check every model on two real phones before it ships. The formats are stable and well documented. The discipline is in the content operation around them.

If you are weighing an AR build and want a straight read on the format pipeline, the device reach and the honest cost of the content side, our team can scope it with you through our app development service, and hand you a fixed plan you own from day one.

Frequently asked questions