STL vs GLB vs OBJ: Pick by What You Are Doing

Most comparisons of 3D formats read like a museum tour. STL was released in 1987, OBJ came from Wavefront, glTF is maintained by Khronos — all true, and none of it helps when you have a model in one format and something that wants another.

The useful question is not which format is best. It is what is the file for, because the two main destinations want opposite things. A 3D printer needs a closed surface and cares about nothing else. A web page needs colour, materials and the smallest download you can manage. A format that is excellent for one is actively bad for the other.

Start with the destination

If it is going to a printer: STL, or 3MF when you need more.

A slicer converts your model into toolpaths. To do that it needs to know exactly what is inside the object and what is outside, which requires a watertight mesh — a closed surface with no holes, no gaps and no faces pointing the wrong way. It does not need colour, because most printers extrude one material in one colour. STL gives the slicer exactly that and nothing more, which is why every slicer ever written accepts it.

If it is going on a web page or into AR: GLB.

Here the requirements invert. Nothing is being manufactured, so watertightness is irrelevant — a model can be a hollow shell of surfaces and look perfect. What matters is that it arrives quickly and looks right, meaning materials, textures and how the surface responds to light. GLB packs geometry, materials and textures into one binary file, and it is what three.js and <model-viewer> load natively.

If it is going to another person's 3D software: OBJ, usually.

OBJ is plain text and has been readable by everything for thirty years. The catch is that it is not one file: materials live in a separate .mtl, and textures in image files next to it. Fine as a folder, awkward as a download.

The size difference is larger than people expect

Here is the same model — a sphere with 642 vertices and 1,280 triangles — exported to six formats and measured:

3MF     14,137 bytes    0.22x
GLB     23,788 bytes    0.37x
PLY     24,560 bytes    0.38x
OBJ     40,715 bytes    0.64x
OFF     43,250 bytes    0.67x
STL     64,084 bytes    1.00x

STL is the largest of the six, and 3MF is under a quarter of its size. That surprises people who think of STL as the lean, minimal option.

Why STL is so big

Because it has no concept of a shared vertex.

Every other format on that list stores a list of vertices and then describes triangles as references into it — vertex 7, vertex 12, vertex 30. A corner shared by six triangles is stored once. STL has no vertex list at all. Each triangle is written independently with its three corners spelled out in full, so that shared corner is written six times.

The numbers from the test file above: the mesh has 642 unique vertices, and the STL contains 3,840 — a six-fold duplication. Binary STL is rigidly regular about it, too, at exactly 84 bytes of header plus 50 bytes per triangle, which the measured file matched to the byte.

3MF is small for the opposite reason: it is a zipped XML container, so the repetitive structure of mesh data compresses well. GLB is small because it stores vertex data as packed binary buffers.

Which conversions lose something

The geometry always survives. Taking a sphere out to STL and back preserved its watertightness and reproduced its volume to four decimal places. What a conversion can lose is anything the target format has no room for — and for these formats that means colour:

• Colour survives: OBJ, PLY, GLB
• Colour is lost: STL, OFF, 3MF

This is not a limitation of the converter. STL has no field for colour in the specification, so there is nowhere to put it. The corollary catches people out in the other direction too: converting an STL to GLB does not add colour. There was never any in the file. You get a format that is capable of carrying colour, containing a model that has none, and you add materials afterwards in Blender or similar.

3MF is on the "lost" list here with an asterisk. The format itself does support colour and multiple materials, and that is one of its selling points for printing — but colour is not carried across a plain mesh conversion into it.

A practical decision list

• Downloaded a model to print, slicer will not accept it. Convert to STL: OBJ to STL, GLB to STL, PLY to STL, 3MF to STL.
• Putting a model on a website. Convert to GLB: STL to GLB, OBJ to GLB. Expect an untextured model if the source was STL.
• Printing in multiple colours or materials. STL to 3MF, then assign materials in your slicer.
• Sending to someone using different software. STL to OBJ or PLY to OBJ — text-based and universally readable.
• Output from a 3D scanner, usually PLY. PLY to STL for printing, or PLY to OBJ to keep the scanned colour.

One thing conversion cannot fix

If a slicer rejects your model as "not manifold" or "has holes", converting it to a different format will not help. That is a problem with the geometry itself — gaps in the surface, flipped normals, self-intersections — and it travels with the mesh into whatever format you put it in. Repair tools such as Blender's 3D Print Toolbox or Microsoft's 3D Builder exist for exactly this, and are the right stop before conversion.

Conversions here run in an isolated, in-memory sandbox with no network access, and the file is discarded as soon as your download is sent. Worth knowing if the model is a client's part or an unreleased product — a 3D file is often the most commercially sensitive thing a person uploads all week.