Why is my STEP to STL model 25.4 times too big?

Because the file was written in inches and read as millimetres. 25.4 is exactly the number of millimetres in an inch, so a unit error is never approximate: it announces itself as a clean factor. Our converter reads the unit declared inside the STEP file and applies it before reporting a number, then reports millimetres by default. That means a correct conversion of an inch-designed file is still 25.4 times larger than the number its author had in mind. The part is not wrong and the conversion is not wrong. The unit the file was written in is.

How do I know if my STEP file was designed in inches?

Divide the bounding box by 25.4 and look at what comes out. Our AP203 test assembly reports 5080 by 2209.8 by 3810 millimetres, and those three numbers divide into exactly 200 by 87 by 150 inches, each axis landing on a whole inch with a remainder below 1.5 times 10 to the minus 14. Its sibling AP214 file reports 200 by 150 by 84 millimetres and divides into 7.874 by 5.906 by 3.307 inches, which are not whole numbers. A box that divides cleanly into whole inches on all three axes was laid out in inches.

Does the whole-inch test mean every vertex in the file is a whole inch?

No, and we measured how far it does not hold. The AP203 file has 54,792 coordinate values. 21,300 of them are whole inches and 33,492 are not, sitting up to half an inch away from the nearest whole inch. The test is a statement about the size of the part, not about every vertex in it. What it catches is the bounding box, and the bounding box is what a designer sets first, on round numbers.

Where do I look in a STEP file to find its unit?

Near the top, in a block that begins with GLOBAL_UNIT_ASSIGNED_CONTEXT. A millimetre file names SI_UNIT(.MILLI.,.METRE.), and an inch file names a CONVERSION_BASED_UNIT with INCH in it. That declaration, not the file extension and not the file name, sets the scale of every number that follows it in the file. If the declaration says millimetres but the bounding box divides into whole inches, the file was drawn in inches and exported as millimetres, which is a setting in the CAD tool rather than a fault in the conversion.

Does this converter rotate, centre or rescale my model?

No, and that is what makes the 25.4 figure diagnostic rather than ambiguous. Because no coordinate is altered on the way out, a clean factor of 25.4 between the size you expected and the size you got cannot have been introduced by the conversion. It was already in the file. The workflow page states this guarantee and the control that proves it.

If I choose inch output, does the geometry change?

No. The inch option divides the coordinate values by 25.4 on the way out and touches nothing else, so it re-expresses the numbers without scaling the shape. On our AP203 assembly the first vertex moved from -3556, -508, -1905 millimetres to exactly -140, -20, -75 inches, three whole numbers, while the triangle count stayed at 6,088 and the binary file size stayed at 304,484 bytes. No triangle appears or disappears, because re-expressing a number is not a change of shape. Note that a binary STL has no unit field at all, so the unit you pick is a promise about the numbers rather than a label inside the file.

Why a STEP model comes out 25.4× too big

The unit and size dimension, decided before you convert rather than after. Every number on this page was measured with the engine this site ships, and npm test re-runs each one and fails on a mismatch.

The short answer: a conversion can be completely correct and still hand you a model 25.4× the size you expected, because the number that doubled was never in the file to begin with. 25.4 is exactly the number of millimetres in an inch, so a unit error is never approximate — it announces itself as a clean factor. The one move that settles it is a division: take the reported bounding box, divide each axis by 25.4, and see whether the results are whole numbers.

A factor of exactly 25.4 means the unit, not the conversion. The file was drawn in inches and read as millimetres. Nothing about the mesh is broken.
Divide the bounding box by 25.4. Whole inches on all three axes means the part was laid out in inches. Our AP203 assembly divides into exactly 200 × 87 × 150.
Read the unit the file declares. It sits near the top under GLOBAL_UNIT_ASSIGNED_CONTEXT, and it — not the extension, not the file name — sets the scale of every number after it.
Check that number against the size you know. Nothing is rescaled on the way out, so a size you did not expect was already in the file before it reached the converter.

1. Read this part first: the two numbers to check

Before you convert, open the file in a text editor and look for one block near the top. A STEP file states its own length unit in a context that begins with GLOBAL_UNIT_ASSIGNED_CONTEXT. It will name something like SI_UNIT(.MILLI.,.METRE.) for millimetres, or a CONVERSION_BASED_UNIT with 'INCH' in it for inches. That single declaration sets the scale of every coordinate that follows it.

Then convert once and take the bounding box the page reports. Divide each axis by 25.4. Whole numbers on all three axes is the fingerprint of a part designed in inches. Fractional results mean it was designed in millimetres and is fine.

The two checks that decide whether a reported size is trustworthy
Where the unit lives	Inside the file, near the top, under `GLOBAL_UNIT_ASSIGNED_CONTEXT`. It outranks the file extension and the file name.
Why 25.4	It is exactly the number of millimetres in an inch. That is why unit errors are always a clean factor and never a vague drift.
The whole-inch test	Divide each axis of the bounding box by 25.4. All three whole means an inch-designed part; any fractional axis means millimetres.
If the size is wrong anyway	Any ratio other than a clean 25.4 is a modelling question, not a unit one — and the verification page has the checks for that case.

2. The whole-inch test, on two real files

This is the measurement we did not expect. We took two assembly files that both declare millimetres, converted both with the same engine at the same setting, and divided each reported bounding box by 25.4. One divides into whole inches on all three axes. The other does not divide cleanly at all.

Two 18-part assemblies, both declaring millimetres, both converted with this engine at Normal. The right-hand columns are the measured bounding box divided by 25.4.
Test file	Bounding box (mm)	÷ 25.4	Whole inches?
as1_pe_203.stp (AP203, 18 parts)	5080 × 2209.8 × 3810	200 × 87 × 150	Yes, all three axes
as1-oc-214.stp (AP214, 18 parts)	200 × 150 × 84	7.874 × 5.906 × 3.307	No

The AP203 file is the interesting one. Its box is 5080 × 2209.8 × 3810 millimetres, and those three numbers divide into 200 × 87 × 150 inches — each axis landing on a whole inch with a remainder below 1×10⁻¹³ of an inch, which is floating-point noise rather than a real fraction. A part laid out on whole-inch dimensions does that. A part laid out in millimetres essentially never does, on all three axes at once.

The AP214 file is the control that keeps this honest. It reports 200 × 150 × 84 mm, which divides into 7.874 × 5.906 × 3.307 inches — not whole numbers, because it was designed in millimetres. Both files declare millimetres. Both are 18-part assemblies. Same engine, same setting, same session. The declaration inside the file tells you what the file claims to be; dividing the bounding box by 25.4 tells you what the part actually was built as.

Both files declare millimetres; only one was built in inches. The teal bars are the millimetre box each file reports, and the orange bars are the same box divided by 25.4. The AP203 row lands on 200, 87 and 150 — whole inches, no remainder. The AP214 row lands on 7.874, 5.906 and 3.307, which is what a genuinely millimetre-designed part looks like. Each row is scaled to its own largest bar, so compare the two rows inside themselves, never against each other.

What this test is worth: one division, no tools, no second application. If your part is the wrong size and the box divides into whole inches, you have found the cause before trusting any output, and you know the fix belongs in your CAD tool’s export settings rather than in the converter.

How far the test actually holds — and where it stops

An honest limit, because it matters if you plan to rely on this. The AP203 file’s bounding box lands on whole inches, but its vertices mostly do not. Of the file’s 54,792 coordinate values, 21,300 are whole inches and 33,492 are not, sitting up to half an inch from the nearest whole inch. So read the test as a statement about the size of the part, not a claim about every vertex in it.

That is not a weakness, it is the right scope for the question. The bounding box is the extremes of the part on each axis, and the extremes are what a designer sets deliberately, on round numbers. The vertices between those extremes land wherever the geometry puts them. A test that only holds for the extremes is still enough to tell you which unit the part was drawn in, because a millimetre part does not land on whole inches three times out of three.

3. What the inch option does, and does not do

The converter can write the numbers in inches, and the useful thing to know is what that actually changes. It divides the coordinate values by 25.4 on the way out and touches nothing else. The workflow page covers the control that proves the mesh is untouched; here is what the same operation does to the one file this page is about.

Take the first vertex of the AP203 assembly. Its coordinates are −3556, −508, −1905 mm. Divided by 25.4 they become −140, −20, −75 — three whole numbers, exactly, with nothing left over. That is the same fact the bounding box tells you, seen from one vertex instead of three: this part was laid out on whole-inch values, and the numbers still say so after you divide.

What does not change is the mesh. The triangle count stays at 6,088 and the binary file stays at 304,484 bytes, because a binary STL is 84 bytes of header plus 50 bytes per triangle and every one of those bytes is a coordinate. Re-expressing a number is not a change of shape, so no triangle appears or disappears.

The inch output control measured on the AP203 assembly
Input	as1_pe_203.stp, 18 parts, declaring millimetres, 6,088 triangles at Normal.
First vertex, out in mm	−3556, −508, −1905.
First vertex, out in inch	−140, −20, −75. Three whole numbers.
What stayed the same	6,088 triangles, 304,484 bytes. Only the coordinate values changed.

Note what that means for the file you download: a binary STL has no unit field at all. The unit you choose is a promise about the numbers, not a label inside the file, so it is worth writing down alongside the download.

Millimetres remain the default. The unit declared inside your STEP file is applied before any number is reported, so whichever you choose, the numbers describe the same physical object.

4. If the number is wrong, here is the order to fix it in

Divide the bounding box by 25.4. Whole inches on all three axes means an inch-designed part, and the converter reported it correctly.
Read the unit declaration in the file. If it says SI_UNIT(.MILLI.,.METRE.) but the box divides into whole inches, the part was drawn in inches and exported as millimetres. That is a CAD-side export setting, and it is worth fixing there rather than patching the output.
Decide which number your downstream tool expects. A slicer expecting millimetres wants the default output. One expecting inches wants the inch option, which divides the coordinates by 25.4 and leaves the mesh identical.
Do not scale the model to compensate. A bigger model is not a more detailed one; the workflow page has the measurement, at three quality settings, showing the triangle count does not move.
Check the result against the size you know. The verification page has the bounding-box check alongside the four that need a file size and an edge count.

If you would rather not read the unit declaration by hand, convert once and read the bounding box the page reports — the whole-inch test needs nothing but that number and a calculator.

The whole thing on one screen

Unit and size rules, each with the number behind it
The 25.4 factor	Exactly the millimetres in an inch. A clean factor of 25.4 is a unit mismatch, not a bad conversion.
Whole-inch test	5080 × 2209.8 × 3810 mm ÷ 25.4 = 200 × 87 × 150, all whole. The control, 200 × 150 × 84 mm, gives 7.874 × 5.906 × 3.307, none whole.
Where the limit is	The bounding box only. 21,300 of the AP203 file’s 54,792 coordinate values are whole inches; 33,492 are not.
Inch option	Coordinates ÷ 25.4 and nothing else. 6,088 triangles and 304,484 bytes either way.
Where the unit is declared	Near the top of the file, under `GLOBAL_UNIT_ASSIGNED_CONTEXT`. It outranks the extension and the file name.

Where these numbers come from

The two bounding boxes and the whole-inch division — produced by running the shipped engine (occt-import-js 0.0.23, a WebAssembly build of OpenCASCADE) in Node.js over the project’s own test files on this machine. npm test re-runs both conversions, divides the measured boxes by 25.4 itself, and asserts that the three AP203 axes land within 1×10⁻¹² of a whole inch while none of the AP214 axes do.
25.4 itself — the exact number of millimetres in an inch, which is why the factor is clean rather than approximate.
21,300 of 54,792, and 33,492 that are not — counted by taking every coordinate value the engine emits for the AP203 file at Normal, dividing each by 25.4, and testing how far it sits from the nearest whole inch. The test recomputes both counts and fails on a mismatch, and it also asserts that the worst case sits within half an inch of a whole number.
The inch option’s behaviour — measured by running the shipped converter’s own writers: the coordinate values are divided by 25.4 and the binary STL is written again, then the byte lengths are compared. Because the record size is fixed at 50 bytes per triangle, an unchanged byte length is an unchanged triangle count. The first-vertex figures are read off the same run.
What we do not claim — the whole-inch test tells you the size a part was laid out at. It does not tell you who exported the file, which tool it came from, or whether the designer intended those dimensions. We do not pretend the 33,492 non-whole vertices are anything other than what they are.
We do not publish the test files — they live in a development folder that is never deployed, so nothing on this site asks you to trust a file you cannot inspect. The check you can run yourself needs no file at all: convert your own STEP, divide the reported bounding box by 25.4, and see whether the numbers are whole.

The workflow page covers the conversion in the order it happens, including the proof that the unit a file declares is honoured and the per-setting quality numbers. The verification page covers the five checks you run on a finished STL. This page is the one dimension that settles the numbers before any of that: units and size.