How to check a STEP to STL conversion without opening the STL

You converted a STEP file to STL. The preview looks right. But "looks right" is not a check: a mesh can be too coarse, in the wrong unit, or missing a shell, and still render like a solid block on screen.

There is one check you can do before opening the file, with a calculator and no CAD software: a binary STL's byte size tells you its triangle count exactly.

The invariant

A binary STL is not an arbitrary blob. It is:

• 80 bytes of header (free-form text, often ignored),
• 4 bytes: an unsigned 32-bit triangle count,
• 50 bytes per triangle: 12 bytes normal + 36 bytes for three vertices + 2 bytes attribute.

So for any valid binary STL:

bytes = 84 + 50 x triangles

That is not a convention or an approximation. It is the file format. Which means you can run it backwards:

triangles = (bytes - 84) / 50

If the division is not exact, the file is not a well-formed binary STL. If it is exact, you still do not know whether the mesh is good, but you know exactly how dense it is, and you know nobody quietly padded or truncated it.

I keep a browser-side converter at stepstl.com, and the size check is the first assertion in its test suite: every file the page writes must satisfy 84 + 50 x triangles, byte for byte. Here is what that looks like across real CAD samples.

Four samples, three quality presets

These are measured outputs, not estimates. The presets are Draft, Normal and Fine; the source files are a 10 mm cube, a conical surface, and two assemblies.

Sample	Draft	Normal	Fine
cube-10x10.stp	12 triangles / 684 B	12 / 684	12 / 684
conical-surface.step	286 / 14,384	516 / 25,884	2,142 / 107,184
as1_pe_203.stp (6,088-triangle assembly at Normal)	3,848 / 192,484	6,088 / 304,484	17,848 / 892,484
as1-oc-214.stp (433,606-byte source)	4,900 / 245,084	7,372 / 368,684	21,116 / 1,055,884

Pick any row and run the formula. The 18-part assembly at Normal: 84 + 50 x 6,088 = 304,484. The conical surface at Fine: 84 + 50 x 2,142 = 107,184. The 10 mm cube at every preset: 84 + 50 x 12 = 684.

Two things fall out of this table.

Planar geometry does not subdivide. The cube stays at 12 triangles whether you ask for Draft or Fine. A quality slider changes how curved faces are sampled, not how flat ones are.

Triangle count is a setting, not a fidelity score. The conical surface goes from 286 to 2,142 triangles — a 7.5x range — for the same geometry. "More triangles" means a closer approximation of the NURBS surface, not automatically a more correct part. That distinction matters when you are choosing a preset for a print or a simulation.

What the triangle count does not tell you

The byte check catches structural problems. It does not catch semantic ones. If the converter read the wrong unit, the mesh can have the right triangle count and the wrong size. If two solids were merged, the count can be plausible and the part unusable.

So the second check is the bounding box: measure the STL's extents and compare them with the size stated in the CAD file. This is where units live. STEP declares its own unit; a millimetre part and an inch part can produce identical triangle counts and completely different objects.

Some tools expose a "convert units" switch that only rescales the numbers on the way out. That is a real distinction: dividing every coordinate by 25.4 changes the numbers, not the topology. In our tests the same 6,088-triangle assembly is 304,484 bytes in millimetres and 304,484 bytes with the inch option, because the triangle count and the per-triangle record size are unchanged. Only the vertex values differ.

Binary versus ASCII

Both formats hold the same triangles; ASCII writes them as text. The cost is predictable: a 12-triangle cube is 684 bytes binary and 2,241 bytes ASCII — 3.28x larger. Across a 27-combination test set (9 CAD samples x 3 presets), ASCII ran 3.3x to 4.0x the binary size for the same geometry. A 6,088-triangle assembly at Normal is 304,484 bytes binary against 1,226,556 bytes ASCII.

Binary is the right default. Choose ASCII only when a tool explicitly wants a text STL you can inspect or diff.

What triangulation loses, by design

STEP stores an exact boundary representation: analytic surfaces, NURBS patches, topology, sometimes colours and materials. STL stores triangles and face normals. Nothing else survives.

That has consequences worth stating plainly:

• Colours and materials are dropped. The STL format has nowhere to put them.
• The mesh is not repaired. If the STEP body has gaps or open shells, the STL will have the same gaps. Triangulation samples the geometry; it does not heal it.
• Volume and area become approximations. Once you are measuring a triangle mesh, any volume you compute is a mesh volume. It converges toward the exact value as the mesh gets denser, but it is not the exact B-rep number.

If you need the exact surface, you need the STEP file, not the STL. The conversion is one-way and lossy on purpose.

The check, in three commands

1. Get the STL file size in bytes.
2. Compute (bytes - 84) / 50 and confirm it is a whole number.
3. Compare the result with the triangle count your converter reported, and check the bounding box against the CAD model's stated size.

That is it. No upload, no account, no plugin. The arithmetic works on any binary STL from any tool, including the one you already use.

If you want to run the size check on a file you already have, there is a browser-side checker here: recover the triangle count from the byte size. If you want the format background first, STEP versus STL covers what each one stores, and units and size covers the unit trap in detail.

Disclosure: I maintain stepstl.com, a static browser-side STEP/IGES to STL converter. The numbers in this article come from its test suite and are reproducible with npm test; the byte formula applies to any binary STL regardless of which tool wrote it.