Why does my STL come out lying down or in the wrong place?

The mesh you download sits in the same coordinate frame as the solid it came from. That sentence is easy to say and easy to check, so this page spends its length checking it: the binary record has no field for a transform, the bounding box survives every quality setting, a model scaled 100× keeps an identical mesh, and an inch file becomes a millimetre file without turning. Every number below is measured by this project’s test suite, and none of it is a promise about what your CAD package should do.

The short answer

This converter does not rotate, align, centre or rescale your part, and the origin it writes is the origin the STEP file already had. A 200 × 150 × 84 mm assembly comes back as 200 × 150 × 84 mm at Draft, Normal and Fine, while the triangle count moves from 4,900 to 7,372 to 21,116. Coordinates are carried through, not re-framed.

So a model that looks like it is lying on its side was already lying on its side in the STEP file. “Up” is not stored in an STL and is not chosen by this converter: it is a convention applied later by a slicer, a printer or a person. If the part is correct in CAD but wrong after conversion, the conversion is not the stage that changed it — and the rest of this page shows the measurements behind that claim rather than asking you to take it on trust.

What a triangle record can hold

A binary STL has one fixed header of 84 bytes — 80 bytes of free text and a 4-byte count of triangles — and then 50 bytes per triangle. Each of those 50 bytes is accounted for: a 12-byte normal, three vertices of 36 bytes in total, and a 2-byte attribute that writers use for colour or leave at zero. That is the whole format. There is no matrix, no separate origin, no scale factor, no part name and no unit field.

This is why the byte count is predictable. A flat 10 mm cube is 12 triangles and lands as exactly 684 bytes, which is 84 + 50 × 12. The same identity holds for every file this project tests, at every quality setting, and npm test recomputes it for each one. The formula is not a rule of thumb about STL files; it is the layout of the record, read back as arithmetic.

The record has nowhere to put a transform. The 84-byte header carries a count, and each 50-byte triangle carries a normal, three vertices and an attribute. Everything about where the part sits is inside those vertex numbers, so “the converter stood it up” would have to mean “the converter rewrote every coordinate”. This one writes the coordinates it read.

The measured box

The claim is checkable at the other end of the pipeline, on the bounding box that the converter reports. Three real files, measured with the engine this site ships:

Bounding boxes reported by the engine. The test suite re-converts each file and fails if a printed number drifts.
Test file	Bounding box	What it proves
`cube-10x10.stp`	10 × 10 × 10 mm	A 10 mm cube stays a 10 mm cube in all three axes; no centring, no normalising.
`as1-oc-214.stp` (18 parts)	200 × 150 × 84 mm	An assembly keeps its own origin and its own three extents.
`as1_pe_203.stp` (18 parts)	5080 × 2209.8 × 3810 mm	A second assembly, a different frame, carried through as written.

The first row is the control. If the converter quietly centred everything, a box that started at the origin would move and the 10 mm cube would report a different set of three numbers. It reports 10 × 10 × 10 mm at Draft, Normal and Fine, and the file is 12 triangles / 684 bytes at all three settings. There is no stage in the pipeline where a coordinate could be swapped without changing one of those figures.

Three settings, one box

The quality setting is the only control this converter offers, and it does not touch the frame. On the 18-part AP214 assembly the triangle count roughly quadruples from Draft to Fine while the box stays put:

The same file at all three settings. Triangle counts move; the bounding box does not.
Setting	Triangles	Bounding box
Draft	4,900	200 × 150 × 84 mm
Normal	7,372	200 × 150 × 84 mm
Fine	21,116	200 × 150 × 84 mm

That difference matters when you are diagnosing a model. A coarser mesh changes how round a curve looks, and it changes the file size by the 84 + 50 × n rule, but it cannot change which way the part faces. If a viewer shows the same part in two different orientations at two quality settings, the orientation is being chosen by the viewer, not by the conversion.

The quality setting moves the triangle count by roughly four times from Draft to Fine and leaves the bounding box untouched. Measured by npm test on as1-oc-214.stp.

A hundred times the size

The strongest test of “nothing is normalised” is to scale a model and watch the box. One curved solid was converted at its own size and again at 100× that size, at the same setting. The bounding box went from 27.033 mm to 2,703.298 mm on the long axis — a clean 100× on all three axes — and the mesh did not change at all: 516 triangles at Normal in both cases, and identical counts at Draft (286) and Fine (2,142) as well.

A converter that centred each part, or normalised it into a unit box, could not produce that result. The 100× part would come back the same size as the 1× part, or its centre would drift to a fixed point. Neither happens. The engine measures the box, reports it, and writes the coordinates it was given. The workflow page’s scaling experiment owns the mesh-quality question behind the same two numbers; this page uses them only as a position test.

Position scales; the mesh does not. The long axis grows from 27.033 mm to 2,703.298 mm, exactly 100×, while the count stays at 516 at Normal. A normalising or centring step would break the ratio or move the box off its own origin. Both rows are measured by npm test on every release.

Inches, millimetres, same axes

The unit path is the other place a coordinate could plausibly be rewritten, so it gets the same treatment. This project ships two cube files that are geometrically identical: one declares UNIT('INCH') and writes its coordinates as multiples of 39.370078740157 (which is exactly 1,000 ÷ 25.4), and its twin declares millimetres directly. Both measure a 1,000 × 1,000 × 1,000 mm bounding box. The declaration inside the file is honoured, and the numbers change by the conversion factor — the three axes stay on the same three axes.

That is the difference between a size error and an orientation error. A clean factor of 25.4 on every axis is a unit mismatch: the units page owns that diagnosis. A part that is the right size but faces the wrong way is not a unit problem at all, and no amount of converting will fix it, because the orientation was decided before the file reached the converter.

Where the orientation came from

A STEP file contains a coordinate system, and the geometry in it is written relative to that system. Whoever exported the file decided where the origin sat and which axis pointed up. The converter reads those solids and tessellates them; it does not know what the part is, which face is supposed to touch the bed, or which direction a printer calls vertical. So it carries the frame through.

That is not a limitation to apologise for. A converter that guessed an up direction from geometry would sometimes be wrong, and it would change a file that was correct. The honest arrangement is the one here: the file keeps the frame its author gave it, and the tool that knows the intent — a slicer, a CAD package, the person holding the part — applies the rotation. The workflow page states the same behaviour in one line beside its unit rules; this page is the measurement behind that line.

What to do about it

Rotate or move the part where the decision belongs. In a slicer, use its place-on-bed control. In CAD, re-export the STEP file with the frame you want. Both are one step and neither changes the mesh.

Two checks separate a real conversion fault from a convention mismatch. First, convert the same file and compare the reported 200 × 150 × 84 mm box with what your CAD package reports; if the three numbers match, the geometry is where it was. Second, look at the triangle count: 12 / 684 bytes for a flat cube, 286 / 516 / 2,142 for the cone at three settings. A count that matches the verification page means the mesh is intact, and what remains is orientation — a rotation to apply, not a conversion to repeat.

Questions this page answers

Does this converter rotate or centre my model?

No. A 200 × 150 × 84 mm assembly comes back as 200 × 150 × 84 mm at Draft, Normal and Fine, while the triangle count moves from 4,900 to 7,372 to 21,116. The coordinates are written through, not re-framed.

Why does my STL lie down after a STEP conversion?

Because the frame in the STEP file is the frame you get. This site does not choose which way is up: the orientation was set by whoever wrote the STEP file, and the STL copies those coordinates. A model that lies down was laid down in the source file.

Can a binary STL store a transform or an origin?

No. A binary STL is an 84-byte header plus 50 bytes per triangle; each triangle carries a 12-byte normal, three vertices of 36 bytes and a 2-byte attribute, and nothing else. There is no matrix, no separate origin and no unit field, so a converter cannot record an orientation change anywhere except by rewriting the vertices.

How do I fix a model that is in the wrong place?

Rotate or move it in the slicer or the CAD package, or export the STEP file in the frame you want. This converter will not do it for you, and that is deliberate: guessing which way is up from geometry alone would change a file that was correct.

Where these numbers come from

84-byte header plus 50 bytes per triangle, 12 triangles / 684 bytes for the 10 mm cube — the binary STL layout and this project’s own conversion, recomputed by npm test for every file at every setting.
10 × 10 × 10 mm, 200 × 150 × 84 mm, 5080 × 2209.8 × 3810 mm — bounding boxes reported by the shipped engine for cube-10x10.stp, as1-oc-214.stp and as1_pe_203.stp. The test suite converts the same three files and compares every axis.
4,900 / 7,372 / 21,116 triangles with one box at all three settings — the same AP214 assembly re-converted at Draft, Normal and Fine; the suite asserts both the counts and the unchanged box.
27.033 mm → 2,703.298 mm at 100×, with identical triangle counts — a live pair of conversions of conical-surface.step and conical-surface-x100.step at all three presets, not a stored table.
1,000 × 1,000 × 1,000 mm for both the inch and the millimetre cube — the control pair cube-in.step and cube-mm.step, read and converted by the suite; the inch file’s declared unit is checked in its source text.
What this page does not print — no monthly search volume, no keyword bid, no claim that any CAD package or slicer handles orientation in a particular way, and no statement about a file this project has not converted. The verification page owns the format rejection list; this page links to it rather than repeating it.

npm test

The command above re-runs every number this project measured. The workflow owns the six steps and the quality presets, the units page owns the 25.4× diagnosis, and the converter is where a STEP file meets the kernel, in the tab.