ASCII vs binary STL: file size, precision, and export

ASCII stores text; binary stores fixed-size records

ASCII STL writes facet normals and vertex coordinates as readable text. Its size depends on the number formatting, spacing, line endings, and triangle count. Long decimal strings can make it bulky even if the surface itself is fairly simple.

Standard binary STL uses an 80-byte header, a four-byte triangle count, and 50 bytes per triangle. Its size is therefore 84 + 50 × n bytes for n triangles. For example, 20,000 triangles occupy 1,000,084 bytes. This is a calculation from the file layout, not a measured compression result or a promise about an ASCII input.

Shared vertices do not compress a binary STL

A processing tool can represent a mesh internally with shared vertices and triangle indices. That saves repeated coordinates in its working representation and supports geometry operations. Standard binary STL does not store that index table: each triangle still writes its own three vertex coordinates.

Consequently, welding identical vertices in memory does not by itself make the exported binary STL smaller. With the same triangle count, a standard binary file keeps the same byte length. To reduce that length further, the exported model needs fewer triangles; ordinary vertex indexing is not a separate STL compression method.

Account for Float32 rounding and export changes

Voloomy reads coordinates into 32-bit floating-point values, matching binary STL's coordinate representation. ASCII numbers with more precision can change in their last digits when rounded to Float32. Do not describe this conversion as a guarantee that every original decimal or physical dimension is preserved exactly.

Export also writes a Voloomy header and rebuilds facet normals from triangle winding. Source solid names and stored normals are not retained, and nonstandard STL colour attributes are not preserved. These are export changes even when the output keeps all triangles. Keep the original if another workflow needs that metadata or coordinate precision.

Separate a format saving from triangle reduction

Compare the source and output triangle counts alongside their byte sizes. If an ASCII model exports as a smaller binary file with every triangle retained, the difference comes from representation rather than fewer faces. That observation does not remove the Float32 rounding and metadata changes described above.

If triangles were reduced, the surface may also have changed. Voloomy's size target and detail settings govern that lossy step. A percentage preset uses the source file's byte count, so a large reduction relative to ASCII input does not necessarily mean the same percentage of triangles was removed.

Choose the format your next tool can use

Check the import requirements of the slicer or CAD application that receives your file. Voloomy accepts ASCII and binary STL and exports binary STL. Inspect the actual download in that next application, including dimensions and important surface features, rather than judging compatibility from the filename alone.

Neither representation records units or proves printability. A file that parses correctly can still have open edges, reversed faces, self-intersections, or walls unsuitable for production. Binary export is a representation choice; it does not repair those problems. Save a separate source copy before using conversion or simplification in a production workflow.

A measured ASCII-to-binary example

The generated sample takes 9,889,331 bytes as ASCII and 1,536,084 bytes after binary export, with 30,720 triangles before and 30,720 after. No triangle reduction is used in this comparison. This sample was generated from Float32 coordinates; other ASCII files can undergo coordinate rounding when read.