Which step in a STEP to STL converter actually changes the format?

The last one. Reading the STEP text, choosing a quality setting and tessellating the surfaces all act on the solid held in memory, and none of them produces a byte. The format becomes STL only at the write, when the triangle list becomes an 84-byte header followed by 50 bytes per triangle. On the 10 mm test cube that is 12 triangles and 684 bytes, and 684 = 84 + 50 × 12.

This page answers one question: at which point in a conversion does the format actually change. The answer is proved with byte counts rather than with a step list, because a step list is a description and a byte count is an artifact. Every figure below is re-measured by this project’s own test suite on every release.

Four stations, and only one of them writes bytes

A conversion that runs in a browser tab has four stations, and it is worth naming them separately because only the fourth has an output format at all.

That separation settles the question in the title. Stations 1 to 3 cannot change the format, because at those stations there is no file to change. Station 2 cannot either, for the same reason: a tolerance pair decides how many triangles station 3 makes, not what station 4 writes. The format is chosen by the writer and by nothing before it.

Where the bytes appear, and how to reverse them

The writer’s record layout is fixed, which is what makes the last station identifiable from the artifact alone. Each triangle spends its 50 bytes on a 12-byte normal, three vertices in 36 bytes and a 2-byte attribute. The header is 80 bytes of free text plus a 4-byte triangle count, which is where the 84 comes from.

Two measured points make the arithmetic checkable on real files:

• The 10 mm cube is 12 triangles at every setting, so its file is 84 + 50 × 12 = 684 bytes, and (684 − 84) ÷ 50 = 12 recovers the count.
• The 18-part assembly reads 433,606 bytes as a STEP file and comes out at Normal as 7,372 triangles and 368,684 bytes, which is 84 + 50 × 7,372; the same subtraction returns 7,372.

Nothing before the write has a length to check. That is the practical use of this page: if you are told the format changed at some earlier step, ask for the byte count at that step, and the answer will be zero.

The setting is a density knob, not a format knob

The only control this converter offers is the quality setting, and it sits at station 2. It changes how tightly the triangles have to follow a curved surface, which changes the triangle count and therefore the length of the file written later. It does not change what is written.

Every byte figure in that table is 84 + 50 × its triangle count: 245,084, 368,684 and 1,055,884. The count moves by more than four times from Draft to Fine and the output column never changes, because the format is decided at station 4 and the setting is read at station 2. These presets are this site’s own choices, not a CAD standard.

When a printed step list drifts from its artifact

Because only the last station writes, the last step of any published walkthrough is the one place where the description can be checked against the product. It is also the place where a description is easiest to get wrong.

One converter’s own walkthrough numbers its steps upload, choose a level, convert, download, and the heading of its final step names a different format from the one the pipeline actually writes. That single line is enough to leave a reader unsure what they were handed, and no earlier step can rescue it, because the earlier steps have no bytes to compare. The rest of that page is qualitative too: benefits with no numbers, levels with names but no triangle counts, and no byte figure anywhere.

The fix is not a better-written step list; it is a step list whose last step can be checked. This site states the accepted inputs and the single output before the first step, and the verification page’s format section is the one authority for that list: .step, .stp, .iges and .igs in, STL out, nothing else. A page cannot drift from its artifact if the artifact’s two checkable properties, its extension and its length, are printed next to the promise.

What you can check without trusting the page

Two properties survive any description, and both are on the file itself.

• The extension. Whatever the last step was called, the file’s suffix is what a downstream tool will believe.
• The length. For a binary STL, (bytes − 84) ÷ 50 returns the triangle count; the cube’s 684 bytes returns 12, and the assembly’s 368,684 bytes returns 7,372. There is no rounding in that identity, so a mismatch is a real fault rather than an artefact.

What this page does not do is claim anything about another tool’s internals. The only claim made here about that walkthrough is the one a reader can repeat: its last step is labelled with a different format from the file the pipeline writes. What happens inside a conversion is a separate question, answered with its own measurements on the pipeline page, and the order of the decisions is on the workflow page. The binary-versus-ASCII choice is a writer’s choice rather than a format change in the sense used here, and it is measured on its own page.

Questions this page answers

Which step in a STEP to STL converter changes the format?

The last one. Reading the file, choosing a quality setting and tessellating the surfaces all act on the solid in memory and produce no bytes; the format becomes STL only when the writer emits an 84-byte header followed by 50 bytes per triangle. On the 10 mm test cube that is 12 triangles and 684 bytes, and 684 = 84 + 50 × 12.

Do the Draft, Normal and Fine settings change the output format?

No. They change how closely the triangles follow a curved surface, so they change the triangle count and therefore the file size: the 18-part assembly is 4,900 triangles and 245,084 bytes at Draft, 7,372 and 368,684 at Normal, and 21,116 and 1,055,884 at Fine. All three are the same binary STL, and the flat cube stays 12 triangles and 684 bytes at every setting. These presets are this site's own choices, not a CAD standard.

How can I tell which format a converter actually gave me?

Two checks that do not require trusting the page. First, the extension of the file you downloaded. Second, its length: for a binary STL, subtract 84 and divide by 50, and the result should be the triangle count the converter reported. A 684-byte file returns 12 triangles, and 368,684 bytes returns 7,372; a file that fails this is not a binary STL whatever the download button said.

Where these numbers come from

• 84-byte header, 50 bytes per triangle, 12 triangles / 684 bytes for the 10 mm cube — the binary STL record layout, and this project’s own output for cube-10x10.stp, re-run at Draft, Normal and Fine by npm test.
• 4,900 / 7,372 / 21,116 triangles and 245,084 / 368,684 / 1,055,884 bytes — the 18-part AP214 assembly as1-oc-214.stp, 433,606 bytes as a STEP file, converted at the three shipped settings; each length is asserted to equal 84 + 50 × its triangle count.
• The setting pairs 0.02 / 0.5, 0.005 / 0.3 and 0.001 / 0.1 — compared cell by cell against the shipped engine/worker.js, so the page and the code that runs cannot disagree.
• What this page does not print — no monthly search volume, no keyword bid, no capacity or timing figure from another converter’s page, and no sentence from one. The competitor observation above is a description of a published step label, not a quotation.

npm test

The command above re-runs every number on this page. The workflow page owns the order of the decisions, the pipeline page owns what the middle of a conversion does and does not do, and the format section is the single authority for what is accepted and what is written.