STEP→STL Your file stays in this tab · nothing is uploaded

Does a STEP to STL converter change the model while converting?

Every converter asks you to trust a middle step you cannot watch. This page replaces the trust with arithmetic. A binary STL has a fixed record, a fixed byte cost per triangle and no place to store a repair, so the things a converter claims to have done to your model either show up in the numbers or do not exist. All of the figures below are re-measured by this project’s own test suite on every release, and none of them is a promise about what another converter does.

The short answer

This converter tessellates and writes. It does not repair, weld, stitch, delete, merge, rotate or rescale anything. The kernel replaces each surface of the solid with flat triangles, the worker copies every one of those triangles into a single flat list, and the writer turns that list into 50-byte records. The 10 mm test cube comes back as 12 triangles and 684 bytes at Draft, Normal and Fine, and the 18-part assembly reports 18 closed shells with zero boundary edges at all three settings while its triangle count runs 4,900 → 7,372 → 21,116.

So the honest description of the middle step is short: triangles in, the same triangles out. What a converter’s page calls “processing” is where a change could be hidden, and the point of this page is that an STL cannot hide one. If a tool deleted a triangle, filled a hole or moved a vertex, the numbers below would move with it, and they do not.

What the output record can hold

A binary STL is an 84-byte header — 80 bytes of free text and a 4-byte triangle count — followed by 50 bytes per triangle. Each record spends its 50 bytes on a 12-byte normal, three vertices in 36 bytes and a 2-byte attribute. There is no matrix, no origin, no unit field, no part name and no place to write “this face was repaired”. Every fact about the geometry lives inside those vertex numbers.

That makes the size predictable from the count alone. The flat cube is 12 × 50 + 84 = 684 bytes at every setting, because a flat face needs no extra triangles no matter how fine the setting is. The 18-part assembly at Normal is 7,372 triangles and 368,684 bytes, from a STEP file of 433,606 bytes; the same identity is recomputed for every sample at every setting by npm test. If the middle of the pipeline added, removed or merged geometry, the byte length would stop matching 84 + 50 × n for the triangle count it reports.

The pipeline drawn: a STEP source becomes one flat triangle list and then 50-byte STL records, with no repair stage between them Three boxes left to right. The first is the STEP source, 433,606 bytes with 18 solid parts. The second is tessellation, which produces a single flat list of triangles, 4,900 at Draft, 7,372 at Normal and 21,116 at Fine. The third is the STL file, 84 plus 50 times n bytes, 368,684 bytes at Normal. Under the middle box a dashed rectangle says that no repair, weld, stitch or merge stage exists between these boxes. The pipeline, drawn One 18-part assembly. The byte and triangle figures are the same file the test suite converts. STEP source 433,606 bytes 18 solid parts Tessellate one flat triangle list 4,900 / 7,372 / 21,116 STL records 84 + 50 × n bytes 368,684 bytes at Normal → → No repair stage exists between these boxes Nothing is welded, re-noded, filled, deleted, rotated or rescaled. Triangles in equals triangles out. The only thing the writer changes is how those triangles are spelled as bytes. Counts measured at Draft, Normal and Fine; the byte figure is this file at Normal.
Two boxes and a copy. The middle of this pipeline is tessellation, not correction. The triangle list that comes out of the kernel is copied into one flat array and written record by record, so a repair would have to appear as a different triangle count or different vertices — both of which the suite would catch.

Why duplicate vertices cannot be seen in an STL

Some converter pages promise to remove duplicate vertices. In an STL that promise is unobservable, and the record layout is the reason: the format has no index buffer. Every triangle stores its own three vertices, so a point shared by six triangles is written six times by definition. There is nothing to deduplicate, because nothing is shared in the first place.

The measured version of that statement uses the worker’s own audit of the merged triangle list. The 10 mm cube is 12 triangles, which is 36 vertex slots, and those slots describe 8 distinct corners — each corner written 4.5 times on average. The 18-part assembly is 7,372 triangles, which is 22,116 vertex slots, and those describe 3,656 distinct points — about six writes per point. A tool that “deleted duplicate vertices” and then emitted an STL would still emit the same 22,116 numbers, because that is what the format requires.

This is worth stating plainly because the claim sounds like a quality improvement. On the mesh side, merging coincident vertices is a real operation with real uses — it changes how a mesh is indexed. It just cannot show up in an STL, and it cannot be audited from the file you were handed. What you can audit is whether a triangle went missing.

The audit a repair would break

The check that does work is the edge count. In a closed shell every edge is shared by exactly two triangles, so the total number of edge uses divides cleanly in half. On the 12-triangle cube the audit reports 36 edge uses ÷ 2 = 18 edges and 0 edges used once. Take one whole face away and the same cube becomes 10 triangles, 17 edges and 4 edges used once — the hole is exactly that list of unpaired edges.

That pair of numbers is the tripwire for a pipeline that edits geometry. A deleted face, a filled hole or a merge that pulled two coincident vertices together moves at least one of them. On the assembly, the audit reports 18 shells, 0 boundary edges and 0 non-manifold edges at Draft, Normal and Fine — the same verdict at every setting, from the same run that counts the triangles. If this converter were quietly tidying shells, that verdict would change between settings or stop being clean.

A closed cube and the same cube with one face removed: 12 triangles and 18 edges with none used once, then 10 triangles and 17 edges with 4 used once Two panels. The left panel is the closed cube: 12 triangles, 36 edge uses, 18 edges, 0 used once. The right panel is the same cube with one face removed: 10 triangles, 30 edge uses, 17 edges, 4 used once. A note says that a weld, a hole fill or a deleted face would move at least one of these numbers. Where a repair would show up Same cube, one whole face removed by hand. Edge uses are counted per triangle, then shared edges are paired. Closed shell 12 triangles · 36 edge uses 36 ÷ 2 = 18 edges 0 edges used once One face removed 10 triangles · 30 edge uses 13 × 2 + 4 × 1 = 30 → 17 edges 4 edges used once A weld, a hole fill or a deleted face moves at least one of these numbers. This converter moves none of them. Both panels are computed from the merged triangle list the page writes, by the same suite that converts the samples.
The tripwire is a pair, not a claim. A closed 12-triangle cube has 18 edges and 0 of them used once. Remove one face and the same cube reads 17 edges with 4 used once. Any stage that deletes, fills or merges changes this pair; tessellation that only subdivides does not.

Three settings, same shells

The quality setting is the only control this converter offers, and it is a curvature knob rather than a repair knob. It changes how far the triangles are allowed to drift from the true surface — 0.02, 0.005 and 0.001 in bounding-box ratio for Draft, Normal and Fine, with an angular limit alongside each — so a curved face gets more triangles and a flat face gets none.

One 18-part assembly at all three settings. Triangles and bytes move; the shell audit does not.
SettingTrianglesSTL bytesShellsEdges used once
Draft4,900245,084 B180
Normal7,372368,684 B180
Fine21,1161,055,884 B180

If the setting were touching topology, the shell count or the boundary count would move with it. They do not: 18 shells and zero unpaired edges at all three, while the triangle count runs up by more than four times and the file follows the 84 + 50 × n rule exactly. That is the difference between choosing a mesh density and asking a tool to alter the part — the first is a knob on this page, the second does not exist here.

What is not in this pipeline

Absences are easier to state than features, because each one is a thing the page cannot do rather than a thing it promises:

Read that list as the answer to the question in the title. The converter changes the representation — surfaces become triangles, a solid becomes a triangle list — and it does not change the part. The representation change is why the triangle count and the byte count are the only numbers that move.

Four stations in the pipeline and one dashed gap: repair, weld and stitch are not stages here A horizontal line with four filled circles labelled read, evaluate, tessellate and write, then a dashed circle labelled absent for repair and weld. Below the line, three measured notes: the cube is 12 triangles and 684 bytes, the closed shell is 36 edge uses divided by 2 equals 18 edges with 0 used once, and the 18-part assembly keeps 18 shells with 0 boundary edges at all three settings. The gap is the claim: nothing in the code inspects a shell and edits it. Four stations, and the one that is not there The pipeline is the four filled stops. The dashed one is the claim. read STEP text evaluate surfaces tessellate tolerance write 84 + 50 × n absent repair · weld The cube: 12 triangles, 684 bytes. The closed shell: 36 edge uses, 18 edges, 0 used once. The assembly at all three settings: 18 shells, 0 boundary edges, 0 non-manifold edges.
The gap is the claim. Read, evaluate, tessellate and write are the four things this converter does. No stage after them inspects a shell, welds a vertex or stitches a hole — which is why the closed cube keeps 18 edges with 0 used once, and the 18-part assembly keeps 18 shells with 0 boundary edges at Draft, Normal and Fine.

A converter that says it repairs

One online converter’s own description runs the job as three steps and names a middle processing stage that attempts to correct geometry problems and delete duplicate vertices. The same page does not say which problems it found, whether it changed anything, or how a customer could see the difference; its prose and its feature table also disagree about colour on the same output. None of that makes the claim false. It makes it uncheckable — and an uncheckable claim about your model is exactly what the arithmetic above is meant to replace.

There is a fair version of the same feature, and it is the one this site chose: say what the stage is, say what it does not do, and print numbers a reader can re-run. “Triangles in, the same triangles out, 18 shells and zero boundary edges” is checkable from the file you downloaded. “We fix geometry” is not, because an STL has nowhere to record the fix.

Questions this page answers

Does a STEP to STL converter change the model while converting it?

A converter that only tessellates does not. This one reads the solid, replaces each surface with triangles and writes those triangles out; nothing is welded, filled, deleted or moved. The 10 mm test cube comes back as 12 triangles and 684 bytes at Draft, Normal and Fine, and an 18-part assembly keeps 18 closed shells with zero boundary edges at all three settings.

Is there an attempt to repair geometry inside this converter?

No. The shipped worker has no repair, weld, stitch or merge routine; it tessellates and copies every triangle the kernel returns into one flat list. Some converters describe a middle step that tries to fix geometry and drop duplicate vertices, but an STL has no vertex index to deduplicate, so that claim cannot be seen in the file you download.

If a converter removed duplicate vertices, would the STL get smaller?

Not in any way the file can show. A binary STL writes three vertices into every 50-byte triangle record: the 12-triangle cube uses 36 vertex slots for 8 distinct corners, and the 18-part assembly uses 22,116 slots for 3,656 distinct points. Nothing in the format is shared between triangles, so a deduplicated vertex list is still written out once per triangle.

How can I tell whether a conversion changed my geometry?

Three numbers on the file you downloaded: the length is 84 + 50 × triangles, the closed shells still have zero edges used once, and the triangle count is one the quality setting explains. The 10 mm cube audits as 12 triangles, 36 edge uses, 18 edges and 0 boundary edges, and the same audit on the 18-part assembly reports 18 shells with zero boundary edges at every setting.

Where these numbers come from

npm test

The command above re-runs every number on this page. The workflow page owns the six steps in order, the upload-safety page owns where a file goes, and the converter is where a STEP file meets the kernel, in the tab.