3MF units: micron, inch and what the STL keeps

A 3MF declares one unit in its model XML, and this converter multiplies every coordinate by that unit’s factor before writing millimetres into the STL. The STL keeps the millimetre numbers but not the declaration, so the file that leaves is only as correct as the unit the source stated.

The six values and their factors

The core specification allows exactly six unit values and sets millimetre as the default when the attribute is absent. Each one maps to a millimetre factor that can be checked with arithmetic:

The inch factor is exact by definition. NIST states that the 1959 yard makes the inch exactly 25.4 mm, and a foot is 12 inches, so 304.8 mm follows. A micron is one thousandth of a millimetre by the SI prefix. None of these are measurements of a particular file.

What does an inch file look like end to end?

A 3 in × 2 in plate declared in inches arrives as 76.2 mm × 50.8 mm: 3 × 25.4 and 2 × 25.4. The Bounds field should read 76.20 × 50.80. If the same geometry is declared in millimetres, the reader applies ×1 and shows 3.00 × 2.00, a part 25.4 times too small. The declaration, not the geometry, decides which reading you get.

Reading the declared unit

Read the root model element:

unzip -l plate.3mf
# Archive:  plate.3mf
#   Length      Name
#     1874     3D/3dmodel.model

unzip -p plate.3mf 3D/3dmodel.model | head -c 300
# <model unit="inch" xml:lang="en-US" xmlns="...">

The <model> element carries unit="...". If the attribute is missing, the default is millimetre, not “unknown”. That default is the trap: a file written in inches but left at the default declares millimetres and contains inch-sized numbers.

Some packages put the root at a different path, so unzip -l comes first. The model part is the file ending in .model; the unit attribute sits on its root element.

What the converter does with the declaration

Open the converter and drop the 3MF. The reader opens the model part, reads the unit attribute, and applies one of the six factors: micron 0.001, millimetre 1, centimetre 10, inch 25.4, foot 304.8, metre 1000. The scaled coordinates are then written as binary STL, and the result panel’s Bounds field reports millimetres to two decimals. The factor comes from the model element, not from the coordinate range.

The Source unit menu is a second multiplier. It offers millimetres, centimetres, metres and inches, not micron or foot.

A micron file or a foot file is read correctly when its declaration is correct, but neither factor has a menu entry. If the declaration is wrong on one of those, fix it in the source file or use a tool that lets you enter the factor. Two menu entries, “Keep the numbers as they are” and “Millimetres (mm)”, both multiply by 1; choosing millimetres does not assert that the file is in millimetres. The declaration is the primary input, and the menu is an override for a declaration you know to be false.

Why the same model can print at two sizes

An STL has no unit field. A slicer reading one assumes millimetres because that is the convention; nothing in the file says so. The conversion therefore has to settle the question at write time.

A model built in inches and written as raw numbers to STL comes out 25.4 times too small, because the slicer reads 1.000 as one millimetre. A model built in metres and treated as millimetres comes out 1,000 times too small, because 0.020 is read as 0.020 mm. The opposite mistake, millimetre numbers declared as metres, comes out 1,000 times too large.

Every one of those files has valid triangles, a clean mesh report and no warning inside it.

A declaration is not a measurement

The unit attribute records intent; the geometry may disagree. A file can declare millimetres and contain inch numbers because the exporter was configured wrong, or because the model was scaled before export and the declaration was not updated. Nothing in the 3MF cross-checks the two.

Verify the declared unit against one known dimension: a 20 mm calibration cube should read 20.00, a 220 mm build volume should read 220.00, and an M6 thread’s nominal outside diameter is 6.00. A file that declares millimetres and measures 25.4 times too small is internally consistent and externally wrong, and no parser can detect it without a reference.

What the STL keeps of the declaration

Nothing. The binary header is 80 bytes, and most writers put a credit line there; this one writes “Binary STL written in the browser”. A 4-byte triangle count follows. There is no room for a unit string and no standard field to put one in.

The receiving program cannot recover the intent, so the number has to be right in the coordinates before the file leaves. A later scale command in the slicer changes the print but leaves the file wrong for the next person who opens it.

Should you convert a micron or metre file at all?

If the downstream tool reads 3MF, keep the 3MF: it carries the declaration and the receiving slicer can apply it. Convert when the receiver is STL-only, and only after confirming the declaration matches the geometry. A metre-unit file converted to millimetres is correct if the source really is in metres; the same numbers read by a tool that ignores the unit are 1,000 times too large.

Micron files deserve a magnitude check before converting. A 0.05 mm feature is 50 microns, and a whole-part bounding box in microns has five or six digits. After conversion, a 20 mm part should report 20.00; a five-digit reading means the micron factor was not applied.

The scale check

Convert, then compare the Bounds field with a 20 mm cube:

What the two test files produced

Two files hold the same 12-triangle cube. One declares millimetres and one declares inches. We ran both through this site’s converter in Chrome on 13 November 2026 and read the exported STL back independently for triangle count, bounds and connected shells.

The triangle and shell counts do not move, because the converter copies geometry rather than resampling it. The bounds change by exactly 25.4×, which is the whole effect of the declaration. The two fixtures are downloadable: cube-20mm.3mf and cube-20in.3mf; the test page lists both runs.

The correction is a re-convert with the right source unit, not a scale command in the slicer. A menu multiplier cannot divide, so the last two rows have no menu fix. The how-it-works page lists the unit step in the pipeline, and the format reference shows which containers declare a unit and which assume one.

By the 3mftostl.io Editor Team, reviewed 14 November 2026. Editorial standards.

How this page was written: the unit list and default come from the 3MF Core Specification, the inch definition from NIST, and the conversion examples are arithmetic on those factors. The two files in “What the two test files produced” were converted with this site’s converter in Chrome on 13 November 2026, and the exported STLs were read back for triangle count, bounds and shell count. No physical print was made. AI-assisted first draft, checked against the sources and reviewed by the Editor Team.

Sources:

• 3MF Consortium, 3MF Core Specification, v1.4.0, model element and ST_Unit — accessed 12 November 2026. Supports: the six allowed values and the millimetre default.
• ISO, ISO/IEC 25422:2025, 3MF specification suite — accessed 12 November 2026. Supports: the published standard edition of the same unit rules.
• NIST, SI Units – Length, 1959 yard and the exact 25.4 mm inch — accessed 12 November 2026. Supports: the inch and foot factors.
• Prusa Research, PrusaSlicer STL.cpp, no unit field is read on import — accessed 12 November 2026. Supports: a slicer treats STL coordinates as millimetres.
• Library of Congress, STL File Format, Binary, 80-byte header, 4-byte count, 50 bytes per triangle — accessed 12 November 2026. Supports: the STL has no unit field.

Related on this site: why a slicer may refuse the 3MF and what a Bambu Studio project keeps.