Blog · Format comparisons
STL vs OBJ — which 3D file format should you use?
STL and OBJ both store 3D mesh data, but they grew up in different worlds. STL came from 3D printing in 1987, OBJ from 3D animation in the early 1990s. The short answer: STL for 3D printing, OBJ for moving meshes between modelling software. The longer answer covers the edge cases where the obvious choice isn't the right one.
The quick comparison
| Feature | STL | OBJ |
|---|---|---|
| Geometry | Triangles only | Triangles, quads, n-gons |
| Materials | None (standard) | Yes, via separate .mtl file |
| Textures (UVs) | No | Yes |
| Normals | Per face | Per vertex (optional) |
| File layout | Single file | Three files (.obj + .mtl + textures) |
| Format type | Binary (default) or ASCII text | Plain text only |
| Animation | No | No |
| File size (cube, 12 triangles) | ~680 bytes binary | ~400 bytes ASCII |
| File size (1M triangles) | ~50 MB binary | ~70 MB ASCII |
| Default home | 3D printing | 3D modelling pipelines |
The fundamental difference
STL describes the surface of an object. Just the surface, as triangles, with nothing else. No colour, no texture, no name, no scale. The format is so deliberately minimal that a 3D printer can use it directly without any preprocessing — which is exactly what it was designed for.
OBJ describes a mesh as something an artist works on. Vertices, normals, UV coordinates, faces that can have more than three sides, named groups, and a reference to a separate material library file that defines colours and textures. It is closer to what's inside a modelling program's scene database than what a printer needs.
That difference cascades into every other choice the two formats made.
Geometry — triangles vs polygons
STL only knows triangles. Every surface, no matter how curved or complex, has to be approximated by enough small triangles to look smooth. A perfect cylinder might be 64 trapezoidal triangles arranged around a circle; double the resolution and it becomes 128.
OBJ supports triangles, quads, and arbitrary n-gons. This matters because most 3D modelling software prefers quads for clean topology — they subdivide better, deform better in animation, and read more naturally when an artist is editing the mesh. A model built in Blender or Maya almost always ships as quads; exporting it to STL forces a triangulation step that loses that structure.
For 3D printing the triangulation is invisible — the slicer triangulates everything anyway. For modelling, keeping quads matters.
Materials and textures
This is where the two formats really diverge.
STL has no material concept at all in its standard form. A few toolchains pack per-face colour into the unused "attribute byte count" field at the end of each binary triangle, but support is inconsistent and most readers ignore it.
OBJ supports a complete material model via a separate .mtl Material Template Library file. The .mtl defines ambient, diffuse and specular colours, transparency, and texture maps — diffuse, normal, bump, specular, alpha. The .obj references materials by name and the .mtl in turn references texture image files by path.
The trade-off: OBJ models are usually a folder, not a file. An .obj on its own is just geometry. If the .mtl is missing, all materials are lost. If a texture file is missing, that channel is dropped silently. STL has no such fragility — it ships everything it has in a single file.
File size
For raw geometry, binary STL is more compact than OBJ. A million-triangle binary STL is around 50 MB; the same mesh as an ASCII OBJ is around 70 MB. Both formats lose dramatically to modern alternatives — Draco-compressed GLB of the same geometry would be 3–5 MB.
ASCII STL is the worst of both worlds — about 280 MB for the same million triangles. Almost nobody writes ASCII STL on purpose.
Software support
Both formats are universally supported. Every 3D printer slicer reads STL. Every 3D modeller reads OBJ. The overlap is also near-total: Blender, Maya, 3ds Max, Cinema 4D, Modo, Houdini, ZBrush, MeshLab all read both. Cura, Bambu Studio, PrusaSlicer, OrcaSlicer all read both as well — though they ship STL by default.
If you are unsure what software the recipient has, OBJ is the marginally safer bet for non-printing use because animation, modelling and rendering pipelines lean toward it. For printing it's STL by a wide margin.
When to use STL
- You are exporting from CAD to a slicer for 3D printing. STL is what every slicer expects.
- You're sharing a print on Thingiverse, Printables or MakerWorld — they all default to STL.
- You need a single-file model with no risk of missing material or texture dependencies.
- You want maximum compatibility with older or unusual software.
When to use OBJ
- You're moving a model between modelling tools — Blender to ZBrush, Maya to Substance Painter, etc.
- You need materials and UV coordinates preserved across the transfer.
- You want quads or n-gons kept intact rather than forcibly triangulated.
- You're sharing a static model with someone whose toolchain isn't a slicer.
When neither is ideal
For animation, neither STL nor OBJ supports it. Use FBX or GLB.
For web or AR delivery, both are several times larger than GLB at the same fidelity and neither supports PBR materials. GLB is the right answer.
For modern 3D printing with multi-material or per-object slicer settings, 3MF supersedes STL — it adds units, colour, materials, build settings, and is the native project format of Bambu Studio, PrusaSlicer and OrcaSlicer.
Bottom line
For 3D printing: STL by default, 3MF if your slicer supports it and you want multi-material or build settings.
For 3D modelling: OBJ for inter-tool transfers, GLB for delivery, FBX if animation is involved.
You only need to pick OBJ over STL or vice versa when you actually have a choice. Most of the time the destination software dictates it.