Every 3D tool offers a list of export formats and almost none of them explain the difference. The choice matters more than it looks, because what separates these formats is not quality. It is what they carry.
Here is the short version, then the reasoning.
| Format | Carries | Use it for |
|---|---|---|
| GLB | Mesh, textures, materials, rig, animation, all in one file | The web, previews, anything modern |
| FBX | Mesh, textures, rig, animation | Unity, Unreal, Maya, 3ds Max |
| OBJ | Mesh and UVs. Materials in a sidecar file | DCC tools, interchange, archival |
| STL | Mesh geometry only. No colour, no UVs | 3D printing |
| USDZ | Mesh, textures, materials | iOS Quick Look, AR on Apple devices |
GLB · the sensible default
One file, everything inside it: geometry, textures, materials, skeleton, animation. No sidecar files to lose, no texture paths to break when you move it.
It is the right choice for the web, for sending someone a model to look at, and for any engine that reads glTF properly, which by now is most of them.
Its weakness is that older pipelines do not read it, and some studio tooling still assumes FBX.
FBX · what a game engine expects
FBX carries a rig reliably, and that is the whole reason it survives. If you are bringing a rigged character into Unity or Unreal, this is the format, even though GLB technically supports skinning too. The importers are simply better tested against FBX and you will hit fewer surprises.
It is a proprietary format with several incompatible versions, which is exactly as annoying as it sounds. If a file will not open, the version is usually why.
OBJ · the one that always works
OBJ is old, plain text, and understood by everything ever written. Geometry and
UVs, and materials in a separate .mtl file next to it.
That sidecar is the catch: move the OBJ without its .mtl and its textures,
and you have a grey model. OBJ carries no rig and no animation at all.
Use it for interchange between modelling tools, and for archival: in twenty years an OBJ will still open.
STL · geometry, nothing else
STL is a bag of triangles. No colour, no UVs, no materials, no rig. That is not a limitation, it is the point: a printer only needs the shape.
If you are slicing, this is the format. One thing to know about generated meshes: they are built to look right, not to be watertight. A slicer will tell you if it is not manifold, and the fix is usually a repair pass rather than a regeneration.
USDZ · AR on Apple hardware
Apple's package format, and what iOS Quick Look reads. Send someone a USDZ and they can put the model on their desk through their phone camera with no app.
Outside the Apple ecosystem it has little reach. For AR anywhere else, GLB.
Which one to actually pick
- Unity or Unreal, rigged character → FBX
- Unity or Unreal, static prop → FBX or GLB, either is fine
- Blender → GLB, it imports cleanly and keeps materials
- Web, or sending it to someone → GLB
- 3D printing → STL
- AR on an iPhone → USDZ
- Keeping it for a decade → OBJ
Each of those goes to a page about that format on its own: what it carries, where it opens, and the one thing about it that catches people out.
The maps question
Whatever you export, the textures baked into it are one thing and the PBR maps are another. If you intend to relight the model, edit its surface, or match it to other assets in a scene, download the map set separately: base colour, normal, metallic-roughness, ambient occlusion, emissive.
That set is what a material author actually works from. The baked texture in the GLB is a result, not a source.
Every format above is included on every plan here, and so is the map zip. If a tool charges more for FBX than for GLB, that is a pricing decision rather than a technical one. The conversion costs the same either way.