STL vs OBJ vs GLB: choosing a 3D format
4 min read · Updated 2026-09-12
3D formats differ from image and audio formats in an important way: they are not all describing the same kind of thing. Some describe a surface. Some describe a surface with a material on it. Some describe an entire scene with a hierarchy, cameras, and animation. Converting between them is not lossy in the compression sense — it is lossy in the sense that the destination may have nowhere to put half of what you had.
What each format is actually for
| Format | What it describes |
|---|---|
| STL | Triangles. Nothing else — no colour, no materials, no units, no hierarchy. |
| OBJ | Geometry plus material references, stored in a separate .mtl file with texture images alongside. |
| PLY | Geometry, optionally with per-vertex colour. Common in scanning and research. |
| OFF | Geometry only. A plain, academic interchange format. |
| 3MF | Geometry plus print-oriented metadata — units, colours, multiple objects. Designed to replace STL. |
| DAE (COLLADA) | A full scene: hierarchy, materials, animation. XML, and verbose. |
| glTF | A full scene, designed for real-time delivery. Sidecar .bin and texture files. |
| GLB | The same as glTF, packed into one binary file with everything inside. |
Why your model arrived grey
This is the single most common surprise. You convert a textured GLB to STL and open it to find an untextured grey mesh.
Nothing failed. STL has no concept of a material, a texture, or a UV coordinate. It is a list of triangles, which is exactly what 3D printing needs and exactly nothing more. The same applies to PLY, OFF, 3MF, and DAE in our pipeline: converting into any of them writes the geometry and drops the appearance.
If you need the look to survive, the target has to be GLB, glTF, or OBJ. If you need the look and a single file, it has to be GLB.
The sidecar problem, and what we do about it
OBJ and glTF both split themselves across several files. An OBJ references a .mtl material file, which in turn references texture images. A .gltf references a .bin file holding the geometry buffers, plus its textures. Hand someone just the .obj and they get an untextured mesh; hand them just the .gltf and they may get nothing at all.
So when a textured model is exported to one of these, the output is packaged as a ZIP containing the main file and its sidecars together. It arrives as one download and unpacks into a working model, rather than as a single file that quietly does not work.
GLB avoids this entirely by embedding everything — geometry, materials, and textures — in one binary file. That is why it has become the default for the web and for AR viewers, and why it is usually the right answer when you are sending a model to someone else.
How the conversion runs
Straight geometry conversions go through trimesh, which loads the mesh and re-exports it. For exports where materials and textures need to survive — GLB, glTF, and OBJ — the job is handed to Blender instead, because faithfully carrying a material graph across formats is work that a geometry library does not attempt.
OBJ has one more wrinkle worth knowing: because a textured OBJ is genuinely several files, uploading one means uploading its sidecars too. The converter accepts a model together with its accompanying .mtl and texture files, so a real textured OBJ can be converted rather than only the bare mesh.
Choosing, by what you are doing
- 3D printing: STL is still the universal answer, though 3MF is better if your slicer accepts it — it carries units and colour, and STL's lack of units is why models so often arrive at the wrong scale.
- Web or AR: GLB. One file, everything inside, and it is what model viewers expect.
- Handing a textured model to another artist: GLB if they just need to look at it, OBJ if they need to open the materials in a DCC tool.
- Scanning and point-cloud work: PLY, which is the one format here that carries per-vertex colour.
- Archiving your own work: the native file from the software you modelled in. Every format in this article is an export, not a source.
Check the scale
STL and OBJ do not record units. A model exported in millimetres and imported into software that assumes metres is a thousand times too small, and the usual symptom is a model that appears to be missing because it is one pixel wide at the origin.
This is not something a converter can fix, because the information genuinely is not in the file. After converting into STL or OBJ, check the bounding-box dimensions in whatever you open it with, before you print it or drop it into a scene.