STL or 3MF: what the newer format actually fixes

STL came out of 3D Systems in 1987 and has been the default 3D printing format ever since. It is a list of triangles. That is the whole format, and its longevity is entirely down to how little there is to get wrong.

It is also why exchanging STL is more annoying than it should be.

What an STL file does not contain

Binary STL is an 80-byte header, a triangle count, and then fifty bytes per triangle: a normal and three vertices as float32, plus two bytes almost nobody uses. There is no index buffer, so every vertex is stored once per triangle that touches it, typically five or six times. There is also:

• No unit. A cube of side 25 might be 25 mm or 25 inches. The file does not say, and the convention is per-application. This is the single most common cause of a print coming out at 2.54 or 0.039 times the size intended.
• No colour or material. Vendor extensions exist and are not interoperable.
• No scene. Multiple objects merge into one triangle soup, losing which triangles belonged to which part and where each was placed on the plate.
• No topology, and no guarantee of one. Nothing says the triangles form a closed manifold. Vertices that ought to coincide are separate float32s, so rounding leaves cracks a slicer has to repair.
• No metadata. No author, no source, no print settings.

The redundancy has a real cost. A million-triangle model is roughly 50 MB as binary STL, against around 15 MB in a format with an index buffer, before any compression.

What 3MF adds

3MF is a zip using the Open Packaging Conventions, the same packaging as .docx, containing XML parts. The mesh is vertices and triangles with real indices, and around it sits everything STL leaves out:

• Units, declared in the file. Millimetres, inches, microns; stated, not assumed.
• Colour and materials, per object or per triangle, in the core specification rather than a vendor extension.
• A build section: which objects to print and the transform placing each on the plate.
• Components, so a part repeated forty times is stored once and referenced forty times.
• Metadata, and extensions for production, beam lattices, slices and volumetrics.

Because it is zipped XML with shared vertices, it is also considerably smaller: the same model is routinely a fifth to a tenth of its STL.

When STL is still the right answer

Support. Every slicer, every mesh tool, every service bureau and every twenty-year-old machine controller reads STL. 3MF support is now good across the mainstream slicers and CAD packages, but "now good" is not "everywhere", and a bureau's upload form is not the place to discover an exception.

The other case is a single-part, single-material print in a workflow that has been working for years. Nothing in 3MF makes that print better. Changing formats to fix a problem you do not have is not an improvement.

Where AMF fits

AMF, standardised as ISO/ASTM 52915, was the earlier attempt at the same problem and it is technically sound: XML, units, colour, materials, curved triangles. It lost on adoption. The 3MF Consortium had the printer and slicer vendors in it, and that turned out to matter more than the specification. Read AMF if you are handed one; do not choose it for new work.

A rule of thumb

Print a single part on a machine you own, from a slicer you already use: STL is fine. Send a model to anyone else, print multiple parts or materials, or care about it being the right size in five years: use 3MF, and keep the CAD original, because both are triangulations and neither is the model.

Converting between them takes a moment either way: STL to 3MF or 3MF to STL, in the browser, with the file staying on your machine. If the original is a CAD file, go straight from that instead: STEP to 3MF keeps the tessellation tolerance under your control rather than inheriting whatever the first export chose.