Unitless STL files: fixing incorrect import scale

Why some STL files land at the wrong size

An STL file describes the surface of an object as a list of triangles. According to the OrcaSlicer wiki, STL is the basic format used for slicing in OrcaSlicer, and other supported formats such as STEP, 3MF, and OBJ are converted to STL during import. Microsoft's 3D Content Guidelines (version 1.3, 2019) state that STL files contain no scale information and the units are arbitrary: the file holds only coordinates, and the application opening it decides which unit to read them in. The cited sources do not document which unit each slicer assumes. So infer nothing from the file extension or from the displayed size alone: compare a known dimension with the value the slicer shows.

The size mismatch comes from the gap between the scale of the coordinates at export and the interpretation of the importing application. The OrcaSlicer wiki notes that how faithfully an STL represents a CAD design depends on that program's export settings, and the scale applied to the coordinates is one of those settings, as the Scale and Scene Unit options of the Blender 4.1 STL exporter show. A modeler set to inches, or a Blender scene whose unit scale is not what you expect, writes coordinates at a different scale from the one the slicer expects. The file does not carry that information. The OrcaSlicer wiki documents a command-line option, --convert-unit, that detects models saved in meters or inches and converts them to millimeters. That detection belongs to the slicer, not the file, and the cited sources describe no equivalent in the graphical interface or in other applications.

The missing unit therefore applies to every STL. The size mismatch only appears when the scale of the coordinates does not match the importing application's interpretation. The Prusa Knowledge Base states that both binary and ASCII STL are supported, and the variant you receive makes no difference to the unit question. To understand what an STL does and does not store compared with a 3MF, read the guide on STL vs 3MF.

Telling a millimeter case from an inch case

Two scenarios illustrate the problem. In the first, the coordinates were created in inches and exported without conversion. If the slicer reads them as millimeters, the part appears roughly 25 times too small, since one inch is 25.4 mm. In the second, the reverse happens: coordinates created in millimeters, opened in a program that interprets them as inches and then re-exported, come out enormous and overflow the bed. In both cases nothing in the file records the original unit, and the displayed size alone does not prove either scenario. Only a known dimension, or the author's documented intent, can settle the question.

A third case comes from scene scale. According to the Blender 4.1 manual, the STL importer and exporter both offer a Scale option and a Scene Unit option that applies the scene's unit to the data. If the author worked with an unusual unit scale, the file can come out with a factor that is neither one nor the inch ratio. Again, that factor cannot be read from the displayed size. It is computed from the ratio between a known dimension and the slicer's value.

To decide between these hypotheses, compare each axis separately against a known dimension. A unit conversion is a single factor applied to all three axes: if the measured ratios are identical on X, Y, and Z, a uniform scale fixes the file. If the ratios differ by axis, a unit conversion is not enough, and the cited sources do not document the cause. In that case go back to the export settings: Blender 4.1 documents Scale and the Forward and Up axes as separate options, to be checked one after the other without jumping to a conclusion.

Checking expected dimensions before you touch the scale

Before changing anything, look for a known dimension. The model's download page, the designer's description, or the original drawing often lists an overall length, a hole diameter, or a wall thickness. Select the part in your slicer and read its size in the object panel. Compare each axis against the expected value.

If nothing is documented, use a reference object. A hole meant for a common screw, a battery pocket, or a mating feature that fits a part you already own gives you a physical anchor. Measure that feature on the real object with calipers and read the matching dimension in the slicer. The ratio between the two is your correction factor. Check that it is identical on all three axes. If it is not, a plain unit conversion will not be enough.

This check keeps you from eyeballing the scale. A part enlarged by guesswork will not mate with the rest of the project. If the overall size is right but fine features are off, you are no longer dealing with a file problem. Move on to the dimensional accuracy guide, which covers material shrinkage and printer settings.

Correcting scale in the slicer without distorting the part

Once you know the factor, apply it in the slicer with its scale tool, in uniform mode, meaning all three axes locked together, so the proportions stay intact. The OrcaSlicer wiki, for example, documents a command-line option --scale that applies a factor to every loaded object and refers to the software's Scale tool. In the interface, type the expected dimension on the axis you verified if the tool accepts target dimensions, and let the other two follow.

The OrcaSlicer wiki documents a command-line option, --convert-unit, that detects models saved in meters or inches and converts them to millimeters. That option was not run for this page, it belongs to OrcaSlicer's CLI mode, and the cited sources do not say whether the graphical interface or other slicers offer an equivalent. If your slicer, in the version you run, offers such a conversion, use it only after establishing that the model really was designed in inches, then confirm in the object panel, for example in OrcaSlicer, that the displayed dimensions match the known dimension.

After correcting in OrcaSlicer, use File > Save Project to retain the project: the wiki documents saving the objects, print settings and configurations. This differs from generic 3MF model export, which excludes printer, material and process information. Keep the original STL so you can start over. For multiple parts in one assembly, apply a common factor only if they share the same original scale and confirmed scale error, then check the mating dimensions.

Fixing the problem at the source in Blender or CAD

When you authored the file, fix the export rather than the import. According to the Blender 4.1 manual, the STL exporter has a Scale option for applying a factor and a Scene Unit option that applies the scene's unit scale to the exported data. A file exported from a scene set to the intended scale comes out with coordinates at that scale. Since the STL does not record the unit, still check a known dimension after importing it into the slicer.

The same manual describes Forward and Up axis settings. Blender uses Y forward and Z up, while other applications use Y as the up axis. This setting does not affect size, but a part lying on its side after import is easy to mistake for a part that is mis-scaled on one axis. Check the two separately. For export preparation, see the guide on Blender for 3D printing.

Blender can also serve as a go-between for a file you received. The manual states that the STL importer has the same Scale and Scene Unit options, which lets you bring a model to the right scale before re-exporting it. The OrcaSlicer wiki adds that how faithfully an STL represents a CAD design depends on the CAD export settings, so mesh resolution matters too, not just the unit.

When the unit is not the issue

Not every size mismatch comes from an inch export. If the ratios differ by axis, the cited sources do not document the cause. Check the Scale setting and the Forward and Up axes of the export separately without jumping to a conclusion. If the overall length is right but holes or mating features are too tight, do not enlarge the whole model: a global scale would also change the dimensions that are already correct. That case falls outside the file and the cited sources. See the dimensional accuracy guide.

The mesh itself can be at fault. The Blender 4.1 manual lists a Validate Mesh import option that checks the imported mesh for corrupt data and fixes it if necessary, at the cost of a slower import that the same page calls often unnecessary. The cited sources do not describe the effect of a damaged mesh on the dimensions a slicer displays. If the reported bounding box seems inconsistent with the visible part, inspect the mesh in the editor before any rescaling, and correct the scale only once the useful geometry is identified.

Finally, consider the source format. The OrcaSlicer wiki notes that STEP, OBJ, and 3MF are converted to STL on import and describes STEP as a more detailed and accurate representation of the original design, and the Prusa Knowledge Base states that STEP files are triangulated during import. The same wiki describes 3MF as more comprehensive (colors, materials, multiple objects) without claiming it is geometrically more precise. If the designer offers a STEP alongside the STL, that is a documented basis for shape fidelity. The cited sources do not document how each slicer handles the unit of those formats, so check a known dimension in the same way.

Sources and limits

• STL - Blender 4.1 Manual Contents Menu Expand Light mode Dark mode Auto light/dark mode
• import_export · OrcaSlicer/OrcaSlicer Wiki · GitHub
• Supported file formats | Prusa Knowledge Base Prusa Prusa Prusa
• 3D Content Guidelines for Microsoft v1.3 (© 2019)
• OrcaSlicer Wiki — CLI Transform

We organize manufacturer and community documentation; we have not measured these products ourselves. The manual for your exact model takes precedence over general guidance.