
STL vs 3MF vs OBJ: picking the right 3D file format
What each format really stores, how many bytes the same mesh costs in all three, why units decide most arguments, and the edge cases that break silently.

Binary STL spends a fixed 50 bytes per triangle and compresses nothing. There are four ways to bring that down, and which one applies depends on whether you still have the CAD source.
Binary STL is a deliberately dumb format: an 80-byte header, a 4-byte triangle count, then a fixed 50 bytes per triangle. File size is 84 + 50 × triangle count bytes, with no compression anywhere in the format. A million-triangle model takes about 48 MB whether it is a turbine blade or a cube that someone subdivided by accident.
The second problem is repetition. STL does not share vertices: every triangle writes out its own three corners in full. On a closed surface each vertex is touched by roughly six triangles, so the same three floats appear six times in the file. Indexed formats such as OBJ, PLY and 3MF store each vertex once, which is where most of the difference comes from.
Before shrinking anything, find out what you are dealing with. For a binary file you can derive the triangle count from the size alone: (file_size - 84) / 50. If that does not come out as a whole number, the file is ASCII or something has been appended to it.
To see the triangle count and bounding box without installing anything, open the file in the 3D viewer.
An ASCII STL spends roughly 250-300 bytes per triangle writing numbers as text; binary spends 50. The conversion is lossless, not a single vertex moves. If you were handed a text-based STL, this is the first step: the file typically drops to a fifth of its size and the geometry is untouched.
When CAD software turns a solid into triangles it works to two thresholds: chord height and angular deviation. The default "very fine" presets will pave a 5 mm hole with hundreds of triangles. Tie the deviation to your print resolution instead: with a 0.4 mm nozzle and 0.2 mm layers, a chord height of 0.02-0.05 mm produces no measurable difference in the printed part while often halving the triangle count.
Order matters. Re-export from the CAD source when you can, and decimate only when you cannot. Re-exporting starts from the mathematical surface; decimation degrades an approximation that is already lossy.
When a mesh is all you have — a scan, a download, a sculpt — the answer is merging triangles. The usual algorithm is quadric edge collapse: it estimates how far each candidate collapse would move the surface and performs the cheapest ones first, so detail disappears from flat regions while sharp edges survive.
A practical rule: 50-70% reduction on functional parts is invisible in print. Past roughly 80% on organic surfaces you start to see faceting in the soft transitions. The browser-based STL reducer lets you set a target ratio and compare the result before you commit to it.
3MF is a zip container holding XML: vertices are indexed and the whole thing is compressed. For the same geometry it is common to land between a fifth and a tenth of the binary STL size. It also carries units, colour, materials and multiple parts, whereas STL has no unit at all, which is exactly why the same model opens as millimetres in one slicer and inches in another. Nearly every current slicer reads 3MF. The 3D model converter moves files between STL, OBJ and 3MF.
| Case | Triangles | Approximate size |
|---|---|---|
| ASCII STL | 1,000,000 | ~270 MB |
| Binary STL, same geometry | 1,000,000 | ~48 MB |
| Binary STL decimated 70% | 300,000 | ~14 MB |
| Same mesh as 3MF | 300,000 | ~2-4 MB |
The 3MF range is wide because compression depends on how regular the geometry is. Flat-heavy mechanical parts compress well; noisy scanned surfaces compress much less.
Decimating a broken mesh makes the damage worse. The algorithms assume a closed surface, so holes, flipped normals and self-intersections turn edge collapses into unpredictable results. Repair first, then reduce.
A slicer intersects the mesh with one plane per layer, so its cost rises with triangle count, but the printed toolpaths do not. A 300,000-triangle model and its 1,000,000-triangle twin produce nearly identical G-code. The difference shows up in slicing time and memory, not in print time.
That is why "more triangles, better print" is misleading. You need enough triangles to represent the surface to the precision the nozzle can reproduce; beyond that you are buying waiting time and disk space. The one exception is scale: the same angular deviation grows in absolute terms on large parts, so on a one-metre object a one-degree deviation can amount to centimetres.
Zipping the file for the slicer. Archiving saves disk space, but the slicer unpacks it and processes the same mesh. Slicing time follows triangle count, not file size.
Confusing print quality with file size. With a 0.4 mm nozzle, a 0.01 mm triangle detail has no physical counterpart in the plastic. Layer height and nozzle diameter set the ceiling on detail.
Decimating your only copy. The operation is not reversible. Keep the original and save the reduced mesh under a different name, so scaling the part up later does not leave you with faceting.
If you generate models from images or codes, the size problem is best solved at the source: in PNG/SVG to STL and QR code to STL, choosing a resolution that matches your print scale beats decimating afterwards.
Not while the deviation stays below your nozzle diameter and layer height. On a printer running a 0.4 mm nozzle at 0.2 mm layers, a 0.05 mm surface deviation is invisible in the printed part. Problems start when decimation is pushed hard on lettering, fine relief and sharp edges.
It depends on the part. 50-70% is routine for mechanical parts and 85-90% is usually fine for 3D scans, while surfaces carrying text or fine detail deserve a visual comparison before you go past about 30%.
For sharing, archiving and handing a model to a slicer, yes: it is smaller, it carries units and colour, and it keeps multiple parts in one file. You may still need STL for older software and for services that accept nothing else.
Scanners cover the surface with a dense, evenly spaced triangle grid and treat noise as detail. Heavy decimation on those files usually removes noise rather than geometry.
No. The slicer unpacks the archive and processes the same mesh. Slicing time is driven by triangle count, so compression saves disk space and nothing else.

What each format really stores, how many bytes the same mesh costs in all three, why units decide most arguments, and the edge cases that break silently.