I still send STL files, but I’d rather send 3MF

Last week a client asked me why I send two files for the same part. “Isn’t STL the standard?” It is. But it’s also thirty-eight years old, and it shows.

I explained that STL only stores triangles. No units. No color. No material. No idea whether the part was drawn in millimeters or inches. I’ve opened STL files in a slicer and watched a 120 mm bracket import as 120 inches because the exporter assumed the wrong unit convention. You catch it fast on a small part, but on a big assembly it can cost a print run.

That’s why the 3MF vs STL which format for 3D printing files question matters. STL is the safe default. 3MF is the better file when the receiving workflow can handle it. I deliver both because I don’t control what the client’s fabricator opens.

What STL actually is

STL was created by 3D Systems in 1987 for stereolithography. It describes a surface as a collection of flat triangles. ASCII STL is human-readable and huge. Binary STL is smaller but still just triangles. The format has no room for units, part names, thumbnails, print settings, or multiple bodies. If you want color, you have to rely on non-standard vendor extensions that different programs interpret differently.

For most simple FDM parts, that’s fine. A single-color bracket, a spacer, a prototype housing — STL carries everything the slicer needs. The mesh just has to be watertight and manifold, which is where most STL file optimization for 3D printing service work actually happens. I spend more time fixing inverted normals and non-manifold edges than I do choosing the format.

What 3MF fixes

3MF was released by the 3MF Consortium in 2015 and became an ISO/IEC standard in 2025. It stores geometry in a ZIP-based XML package, and it carries a lot more than triangles.

The model element has an explicit unit attribute, defaulting to millimeter. So a 3MF imports at the right scale in Cura, PrusaSlicer, or Bambu Studio without me having to guess. It supports multiple objects in one file, each with its own transform. It can embed a thumbnail, base materials with display colors, and even texture-mapped color through the Materials and Properties Extension. For multi-material or multi-body prints, that’s a big deal.

3MF files are also usually smaller than binary STL because the geometry is compressed inside the ZIP package. On detailed meshes the difference is noticeable, especially when I’m emailing files back and forth.

The catch: not all 3MF files play nice

Here is the part that took me a while to learn. “3MF support” does not mean “3MF interoperability.”

Bambu Studio can export a generic core 3MF, but its default project save writes Bambu-specific extensions: build plates, painted supports, filaments, process settings. PrusaSlicer and Cura may refuse to open those files or report them as empty. The same thing happens in reverse. Cura writes UltiMaker Cura project 3MFs that carry per-object settings and machine profiles. PrusaSlicer can usually read the geometry, but it ignores the Cura-specific metadata.

So when I send a 3MF to a client, I make sure it is a plain, generic 3MF — not a project file. If the fabricator uses the same slicer I do, I’ll send the project 3MF separately. Otherwise I stick to geometry-only 3MF plus an STL fallback.

How I choose in practice

For a simple functional part — a bracket, a spacer, a drill guide — I default to STL. Everyone can open it, and there is nothing in the part that needs the extras 3MF provides.

For assemblies, multi-body parts, or anything with color or material assignments, I prefer 3MF. One file, correct scale, multiple objects. It reduces the chance of someone importing half the parts at the wrong size.

For online print services or clients who just want “a printable file,” I send STL. Those services are built around STL, and I’d rather not introduce a format their pipeline might not expect.

For internal iteration with a client who uses PrusaSlicer or Bambu Studio, I send 3MF. We keep orientation, supports, and material choices embedded. It saves a round of “did you mean this filament?” emails.

The workflow is what matters

The format debate is less interesting than the workflow around it. I still run the same checks on both: watertight mesh, no inverted normals, reasonable polygon density, overhangs that match the chosen printer, and support strategy that fits the material. A bad mesh in 3MF is still a bad mesh.

But 3MF removes one whole class of failure: the scale-and-units failure. That alone makes it my preferred export when I know the destination can read it. Until every service and legacy machine catches up, though, STL stays in the delivery folder. Not because it’s better, but because it’s the lowest common denominator that still works.

[IMAGE: A dark studio comparison of two 3D model file representations. On the left, a faceted STL mesh shown as amber wireframe triangles on a dark surface. On the right, a smooth 3MF model with a small color/material thumbnail badge, multiple body groups, and a millimeter unit label. Graph paper texture background at low opacity. Clean, technical, no text. 3:2 aspect ratio.]