Blog · Format comparisons
STL vs 3MF — the case for moving on from STL
STL has been the 3D printing default for almost forty years. 3MF was designed in 2015 specifically to replace it. In 2026, every major slicer — Bambu Studio, PrusaSlicer, OrcaSlicer, Cura — reads 3MF, and the modern ones write it by default. So why does anyone still use STL? Mostly habit and compatibility. Here's when each one is the right choice.
The head-to-head
| Feature | STL | 3MF |
|---|---|---|
| Units | None (unitless coordinates) | Required (millimeter, inch, etc.) |
| Colour and materials | None in standard form | Per-object, with textures supported |
| Multi-material printing | No | Yes, fully supported |
| Slicer settings inside file | No | Yes, via extensions |
| Build orientation / arrangement | Not stored | Yes |
| Multiple parts in one file | Single soup of triangles | Named objects with transforms |
| Thumbnail preview | No | Embedded in file metadata |
| File size (same model) | Baseline | 20–40% smaller (ZIP-compressed) |
| Format type | Binary or ASCII | XML inside a ZIP archive |
| Year created | 1987 | 2015 |
What 3MF fixes
STL was a 1987 format designed for one job: feeding triangles to an SLA printer. Every other capability that a modern 3D printing workflow needs has had to be bolted on top of it through non-standard hacks. 3MF was designed from scratch with those needs in mind.
Units, finally
STL stores vertex coordinates as plain numbers. The convention is millimetres, but there's no way to mark that in the file. Open an STL exported from a US-default CAD package that assumed inches and you get a model 25.4 times the intended size — silently. 3MF requires a unit attribute on the model root, so the receiving slicer always knows what 1.0 means.
Colour and material assignment
STL has no concept of colour. Some toolchains misuse a per-triangle attribute field to smuggle in vertex colour, but nothing reads it consistently. 3MF supports colour as a first-class citizen — per object, per material, with optional textures. For multi-colour FDM (Bambu A1 with AMS, Prusa MMU, multi-toolhead systems) the assignment of which body uses which material is part of the file rather than something you have to rebuild every time in the slicer.
Slicer settings travel with the file
3MF reserves namespaces for extensions, and slicer vendors use them aggressively. A Bambu Studio 3MF carries every per-object setting you configured — supports painted on, seam locations, modifier meshes, infill type, walls, top/bottom layers. PrusaSlicer and OrcaSlicer do the same in their own namespaces. Open the 3MF in the same slicer and you get the project back exactly as you left it.
Open it in a different slicer and you still get the geometry, units, and base materials — the geometry round-trips losslessly. Just not the slicer-specific bells and whistles.
Multiple parts as actual parts
STL flattens everything into a single triangle soup. A 4-part assembly comes out as one shapeless mesh; you have to re-split it manually in the slicer using "split by loose parts" or similar. 3MF stores each object with its own name, transform, and material assignment. Open a 3MF in the slicer and the four parts arrive as four parts.
Smaller files
3MF is XML inside a ZIP archive. The XML overhead per triangle is much higher than binary STL, but ZIP compression more than makes up for it — a typical 3MF is 20–40% smaller than the same geometry as binary STL.
When STL is still the safer choice
3MF isn't always the right answer. STL beats it on:
- Maximum compatibility. Some older slicers, niche printers, and obscure CAD packages read STL but not 3MF. If you don't know the recipient's software, STL is the safer least-common-denominator.
- Sharing on platforms that default to STL. Thingiverse still treats STL as the canonical format. Many older Patreon model packs ship STL only.
- Pure geometry transfers without metadata. If you want to send a model with no slicer settings attached, plain STL communicates "geometry only" more cleanly than a 3MF where you'd have to remember to strip extensions.
- Tooling that hasn't caught up. Many 3D printing utilities — mesh repair tools, hollow generators, support generators — still expect STL input.
The realistic recommendation
For your own exports out of CAD or modelling software, default to 3MF if your slicer is Bambu Studio, PrusaSlicer or OrcaSlicer. You get units, multi-material if you use it, and the option to bundle slicer settings later.
For sharing on Thingiverse, Printables or Patreon, ship both — most platforms accept either, and STL is the safer fallback for users on older software.
For receiving files from other people, you have no choice — open whatever you got. Both work in modern slicers and modern viewers.
The transition has already started
Bambu Lab made 3MF the default export from Bambu Studio. Prusa Research did the same with PrusaSlicer. Major mod sites like MakerWorld and Printables explicitly support uploading 3MF projects with slicer settings preserved. New 3D printing workflows are increasingly 3MF-first.
STL won't disappear — there are millions of STLs on Thingiverse and decades of tooling that expects it — but for new files in 2026, 3MF is genuinely the better default.