Benchmark
What actually shrinks an STL file, and what each method costs in accuracy
Which methods reduce the size of an STL file, and how far does each one move the surface?
Result
One change is free: rewriting an ASCII STL as binary takes the same 69,451 triangles from 19,744.8 KB to 3,391.2 KB, a 82.8 percent reduction with byte-identical geometry. Everything else costs accuracy. Decimating to 10 percent of the faces reaches 339.1 KB but moves the surface by a mean of 0.0162 mm. Draco compressed GLB is the smallest result at 46.9 KB while keeping every face, at a mean deviation of 0.0040 mm, but it is not an STL and no slicer will open it.
Nine exports of the same model
| Export | Size (KB) | Gzipped (KB) | Triangles | Lossy | Mean deviation (mm) | 99.9th percentile (mm) | Note |
|---|---|---|---|---|---|---|---|
| STL, ASCII | 19,744.8 | 5,900.5 | 69,451 | No | none | none | baseline as many exporters default |
| STL, binary | 3,391.2 | 2,085.5 | 69,451 | No | none | none | identical geometry |
| GLB | 1,222.9 | 751.4 | 69,451 | No | none | none | identical geometry, web format |
| STL binary, 50% of faces kept | 1,695.6 | 1,011.5 | 34,725 | Yes | 0.0032 | 0.0207 | |
| STL binary, 25% of faces kept | 847.9 | 483.1 | 17,363 | Yes | 0.0074 | 0.0423 | |
| STL binary, 10% of faces kept | 339.1 | 181.4 | 6,944 | Yes | 0.0162 | 0.0997 | |
| STL binary, 5% of faces kept | 169.7 | 86.1 | 3,473 | Yes | 0.0295 | 0.3907 | |
| STL binary, 2% of faces kept | 67.9 | 32.1 | 1,389 | Yes | 0.0658 | 0.9496 | |
| GLB + Draco | 46.9 | 46.6 | 69,451 | Yes | 0.0040 | 0.0143 | all faces kept; loss is quantisation, not decimation |
The first three rows carry identical geometry, so the size difference between them is pure encoding. Everything below them trades surface accuracy for bytes, and the deviation columns are what that trade costs.
Why deviation is reported in millimetres and not in percent of faces
Face count is the number every tool shows and the one that tells you least. Halving the triangles of a smooth surface and halving the triangles of a surface covered in fine detail are not the same operation, and neither result is described by the word 50 percent. What decides whether a print looks wrong is how far the simplified surface moved, measured against what the printer can resolve. A 0.4 mm nozzle laying 0.2 mm layers cannot express a 0.0162 mm shift, which is why 10 percent of the faces is survivable here and 2 percent, at a 99.9th percentile of 0.9496 mm, is not.
Gzip is already happening and is not a fourth option
The gzipped column is there to prevent a common double count. Web servers compress on the wire by default, so a 3,391.2 KB binary STL is already arriving as roughly 2,085.5 KB without anyone choosing anything. Compressing the file yourself before upload does not add to that; it just moves where it happens.
How this was measured
The Stanford Bunny (bun_zipper.ply, 69,451 triangles) from the Stanford 3D Scanning Repository, scaled to 50 mm tall so that deviations can be read against real printer resolution rather than as unitless ratios. It is a scan rather than clean CAD, and it is not watertight: the underside was never scanned. That does not affect file size, and it is stated here so nobody mistakes it for a print-ready file.
- Software and versions
- trimesh 5.1.0
- Date measured
- 2026-08-31
- Script
scripts/measure-stl-size.py- Raw data
- stl-size-2026-08-31.json
This data is published under CC BY 4.0. Reuse the numbers freely, with a link back so a reader can check the method.
What this does not show
Stated so the result is not read wider than it goes.
- One model. A scan of an organic form decimates differently from hard surface CAD, where flat regions collapse to very few triangles with no deviation at all.
- Deviation is measured from the original mesh, not from the physical object the scan came from.
- No slicer was run. Whether a given deviation shows in a print is argued here from layer height and nozzle width, not observed.