Why is my STL file so big after converting STEP to STL?
This question keeps arriving when people get a 100 kilobyte STL out of a kilobyte STEP file and wonder what happened. Every number below was measured on the machine that wrote it and is re-checked by npm test. Nothing here is a rule of thumb.
The short answer
An STL file size is exactly 84 bytes of fixed header plus 50 bytes per triangle. The entire size is determined by the number of triangles inside it. That number depends only on two things: how much curved geometry your STEP file contains, and what quality setting you chose when converting.
So if your STL grew 7.5 times between Draft and Fine settings on the same STEP file, that is not a bug, not a compressor malfunction, and not your file getting corrupted. It is the quality dial working normally. A flat cube will stay 12 triangles = 684 bytes at every quality setting forever, because flat faces do not need any approximation. A curved surface can be three times denser, five times denser, or seven and a half times denser depending on how tight you set the tolerance.
1. The exact formula that explains it
A binary STL file has two parts that affect its total size:
- An 84-byte header at the start, which holds an 80-byte comment and a 4-byte triangle count. Nothing you do changes this number, so you can treat it as fixed overhead.
- Exactly 50 bytes per triangle after that, which holds the normal vector (12 bytes) plus three vertex positions (36 bytes) plus a 2-byte attribute slot. So every triangle adds exactly 50 bytes to the file.
That gives you the complete, exact identity: file size = 84 + 50 × triangle count. There are no other bytes in a binary STL. If you know how many triangles you have, you know the file size. If you know the file size, you can work out the triangle count. This is the first of the five checks on the verification page.
2. The only thing that changes it: surface curvature
The quality setting (Draft / Normal / Fine) controls how tightly the converter tessellates curved geometry into flat triangles. It has no effect whatsoever on flat geometry, because a flat face is already a triangle — it needs no approximation, and the converter will always spend exactly two triangles on it, whatever the setting.
This is measured on our own test files, with no room for interpretation:
| Part | Draft | Normal | Fine | Flat or curved? |
|---|---|---|---|---|
| 10 mm flat cube | 12 / 684 B | 12 / 684 B | 12 / 684 B | All flat |
| Rounded cube | 40 / 2,084 B | 56 / 2,884 B | 140 / 7,084 B | Mixed |
| Conical surface | 286 / 14,384 B | 516 / 25,884 B | 2,142 / 107,184 B | All curved |
The flat cube is identical across all three rows: 12 triangles, 684 bytes. The rounded cube (which mixes flat faces with curved edges) grows by a factor of 3.5 from Draft to Fine. The cone (all curved) grows by 7.5× from Draft to Fine. The quality dial's only job is to decide how many triangles those curved surfaces need.
3. Why the STEP file itself was so small
A STEP file is a text file that stores exact geometry: a cylinder is a radius, a height and a position, written once, not a hundred small triangles. So its size follows how complex the CAD data is — how many distinct surfaces it describes — not how finely you want to tessellate them for 3D printing or viewing. A STEP file holding a flat cube is a few hundred bytes; the STL output is 684 bytes. A STEP file holding our cone is a few kilobytes of text holding a conical surface parameterised by a half-angle and a radius; the STL output is 107,184 bytes of flat triangles. The STEP file stores the question; the STL file stores the answer.
The whole thing in one screen
| File size formula | Binary STL = 84 bytes of header + 50 bytes per triangle. No other bytes. |
|---|---|
| Flat cube, any setting | 12 triangles = 684 bytes. Quality setting cannot change this. |
| Curved cone, Draft to Fine | 286 → 516 → 2,142 triangles. File size follows exactly. |
| What changes the size | Curved geometry and the quality setting. Flat geometry never changes. |
| What does not change it | The size of the STEP file you started with — that stores exact geometry, not triangles. |
| Why yours grew | You converted a curved part and moved up the quality dial. The growth is the dial working. |
Where these numbers come from
- 84 + 50 × triangles — the published binary STL record layout, cross-checked against the reference STL shipped with the engine vendor's own test set.
- 12 / 40 / 56 / 140 / 286 / 516 / 2,142 triangles — produced by running the shipped engine (occt-import-js 0.0.23, a WebAssembly build of OpenCASCADE) in Node.js over the project's own test files at Draft, Normal and Fine.
npm testre-runs every count and fails on a mismatch. - Conical surface file sizes: 14,384 / 25,884 / 107,184 bytes — 84 + 50 × 286, 516, 2142 respectively, computed by the same test suite that measures the triangle counts.
If you want to run these checks on your own conversion, the verification page has all five checks, starting with recovering the triangle count from the file size. The faceted STEP page covers why flat faces are the real health check, and the converter reports the triangle count, bounding box and piece count for your own file after every run.