Binary or ASCII STL? The same model in two files, measured by the byte

A binary STL and an ASCII STL carry the same triangles and the same geometry; the only difference is how each triangle is written to disk. This page writes one model both ways, measures the two files, and shows why the size gap between them is not a fixed number. Every figure here is re-run by the test suite before the page can publish.

The short answer

Pick binary unless a tool explicitly asks for text. A binary STL stores each triangle in a fixed 50 bytes behind an 84-byte header, so the file size is decided by the triangle count alone: the flat 10 mm test cube is 12 triangles and 684 bytes, while the same cube written as ASCII is 2,241 bytes — 3.28× larger for identical geometry. The gap is not a constant. Across the project’s test set of 27 sample-and-preset combinations, ASCII runs from 3.276× to 4.030× the binary size, and on the 18-part assembly at Normal the two files are 304,484 bytes and 1,226,556 bytes, a ratio of 4.03×. Both are the same mesh; binary is the smaller, faster one to hand to a slicer.

What each writer puts on disk

A binary STL is a fixed-size record. The file opens with an 80-byte header and a 4-byte triangle count, then each triangle is written as twelve 32-bit numbers — a normal and three vertices — for 50 bytes apiece. So a binary file of n triangles is always 84 + 50 × n bytes, and no geometry changes that. A flat cube with 12 triangles is 84 + 50 × 12 = 684 bytes at Draft, Normal and Fine alike, because a plane needs 12 triangles at every setting. The identity is the reason a file length tells you what is inside it; the verification page makes recovering the triangle count from the byte count its first check.

An ASCII STL is the same data spelled out. Each facet becomes a line of keywords and its three vertices are printed as decimal text — a vertex 10.000000 10.000000 0.000000 line and so on — wrapped in a solid … endsolid envelope. Nothing about that is fixed-size: a coordinate near zero costs a few characters, a coordinate of many digits costs more, and the reader has to parse text where the binary writer simply copied numbers. The ASCII cube is not a longer binary file; it is the same 12 triangles rendered as printable characters, which is exactly why its size tracks the coordinates rather than the triangle count.

The same geometry, written both ways

Both writers ship in this site’s worker, so the two files below come from a single conversion run and are compared byte for byte by the suite.

The whole test set is wider than the two rows above: across 27 sample-and-preset combinations the ratio lands between 3.276× and 4.030×. So the honest one-line answer to “how much bigger is ASCII?” is “between three and four times, for the same triangles.”

Why the ratio moves: the cost of one triangle

Divide each file by its triangle count and the mechanism appears. For the flat cube, the binary file is 684 ÷ 12 = 57.00 bytes per triangle and the ASCII file is 186.75 bytes per triangle. For the 18-part assembly the binary file is 50.01 bytes per triangle and the ASCII file is 201.47 bytes per triangle. The two costs move in opposite directions and that is the entire story of 3.28× becoming 4.03×:

• The binary cost is a fixed 50 bytes per triangle plus an 84-byte header. On a small file the header is spread over few triangles, so it reads high (57.00) and falls toward the flat 50 on a large one (50.01). It never tracks the coordinates.
• The ASCII cost grows with the coordinates, not the count. The cube’s vertices are small round numbers, so each printout is short and the cost sits at 186.75 bytes per triangle; the assembly’s vertices carry more digits, so the same twelve numbers per triangle now take 201.47 bytes.

That is why the ratio is a band rather than a value: it is a property of the model’s coordinates, not of the STL format. The triangle-count page owns how many triangles a part needs; this page only answers what those triangles cost in each of the two writers. If the file is already too large, the lever is the preset, and the STL-size page owns that question.

When ASCII is the right pick

ASCII exists because a human or a script sometimes has to read the file. If a tool only accepts a text STL, if you want to grep a vertex out of it, or if a pipeline downstream cannot take binary, the choice is made for you — and then the extra 3× to 4× of bytes buys readability that binary cannot offer, because a binary file’s numbers are packed and not meant to be read. In every other case the honest advice is binary. This converter writes binary STL by default and keeps an ASCII option for the cases above; switching to it changes only the writer, never the triangle count, and npm test measures both files from the same mesh.

Questions this page answers

Why do converters offer both a binary and an ASCII STL?

Because the two files answer different needs from the same mesh: binary is the compact form a slicer wants, and ASCII is the human-readable form you can open and edit in a text editor. Early converters listed them side by side as two output choices, and the split survives because both uses are real. The cost of the choice is measurable - for the same triangles an ASCII file runs 3.276x to 4.030x the binary file.

Which is smaller, binary or ASCII STL?

Binary, always. A binary STL is a fixed record of 84 bytes of header plus 50 bytes per triangle, so its size is set by the triangle count; ASCII writes each vertex as decimal text and grows with the coordinates instead. For the flat 10 mm cube that is 684 bytes against 2,241 bytes (3.28x), and for the 18-part assembly at Normal it is 304,484 bytes against 1,226,556 bytes (4.03x).

Is ASCII STL ever the right choice?

Only when something demands a text file. If a tool, a script or a colleague has to read the STL as text, or a pipeline only accepts ASCII, the choice is made for you; otherwise you are paying more bytes for the same mesh. This site writes binary STL by default and keeps the ASCII option for exactly those cases; both are re-measured by the test suite.

Where these numbers come from

• 684 bytes and 2,241 bytes — the flat 10 mm cube converted at Normal by the two shipped writers, and the identity 84 + 50 × 12 = 684 closing on the binary side; the ratio 2,241 ÷ 684 = 3.276 is the cube’s own comparison.
• 304,484 bytes and 1,226,556 bytes — the 6,088-triangle 18-part assembly at Normal, written both ways in one run; 84 + 50 × 6,088 = 304,484 and the ASCII file’s ratio 1,226,556 ÷ 304,484 = 4.028.
• 3.276× to 4.030× — the minimum and maximum of the 27 ratios the suite computes, one for each sample-and-preset pair it converts.
• 57.00, 186.75, 50.01 and 201.47 bytes per triangle — each figure is the byte count above divided by that file’s triangle count (684 ÷ 12, 2,241 ÷ 12, 304,484 ÷ 6,088, 1,226,556 ÷ 6,088). They are divisions of already-measured numbers, not a second measurement.
• What this page does not claim — ASCII is not called a worse format, only a larger one for the same mesh; its readability is the reason it exists. The verification page owns the format rejection list, and this page links to it rather than repeating it.

npm test

The command above re-runs every number on this page. The verification page owns the file-size identity and the rejection list; STEP vs STL owns what each format keeps and drops; the STL-size page owns why a file is large and how to shrink it; the triangle-count page owns how many triangles a part needs; and the converter is where the two writers run, for free, in the tab.