3MF opens as a ZIP, not a model? Convert it back

A 3MF is a ZIP package by design; an archive window proves nothing. A slicer refusal falls into one of five categories: the file association never reaches the slicer, the reader cannot parse the package’s extension, the download is truncated, the declared unit is wrong, or the reader misses objects stored in referenced parts. Convert to STL only after the symptom tells you which one you have.

A ZIP icon is not a model error

The 3MF Core Specification builds on the Open Packaging Conventions, so every 3MF is a ZIP container with a content-types part, a relationships part and at least one model part. If a double-click opens WinZip, 7-Zip or macOS Archive Utility, the association is doing what the extension allows; the geometry is still inside.

If the association is the only problem, reassign it: Default apps on Windows, Get Info > Open with on macOS. Neither changes the file, and neither explains a slicer that loads the package and then fails.

Test it by opening the file from inside the slicer, or by listing the archive:

unzip -l plate.3mf

A valid file shows a 3D/3dmodel.model part. If the listing shows model data across 3D/Objects/*.model, the file uses the Production Extension, covered below.

The first entries also tell you whether the archive is a 3MF at all. A 3MF package opens with [Content_Types].xml, _rels/.rels and a model part; a ZIP of STL files has none of those, whatever its extension says. That distinction matters when a file was renamed by hand: the slicer sees a ZIP and reports a parse error, while an archive tool opens it happily.

Which failure are you looking at?

“Unsupported file format” or “no mesh found” points at the extension or a renamed archive: the reader parsed the package and found nothing it could draw. A checksum, CRC or unexpected-end-of-file error points at the bytes. A parse error means the extension; a CRC error means the bytes.

Why Bambu Studio files fail in other slicers

Bambu Studio writes project files, and its default 3MF layout uses the Production Extension. That extension moves object data out of the root model into other parts and uses a path attribute to point at them. A reader that has not implemented that indirection parses the root, sees build items that reference objects it cannot resolve, and stops with an empty scene.

Bambu’s compatibility page states the consequence directly: some software and slicers do not support the extension and cannot open the files. The page also records that PrusaSlicer merged a support patch on 21 March 2024, so a build older than that is a real candidate for the failure. If the slicer is current and the file still fails, suspect the package rather than the slicer.

Support differs by slicer. Bambu Studio reads and writes the extension from version 1.8.3 (Bambu’s compatibility page). PrusaSlicer added p:path handling in 2.7.3, released 28 March 2024, so earlier builds are the ones to update. Bambu’s page lists Cura’s pull request 15761 as unanswered, and we found no Cura documentation claiming support.

Check the package before converting

Two commands separate a damaged archive from an unsupported one:

unzip -t plate.3mf
unzip -p plate.3mf 3D/3dmodel.model | head -c 600

unzip -t tests the archive. A truncated file fails here before any slicer sees it, and no converter can rebuild the missing bytes. The second command prints the root model header. Read the <model> element: unit="millimeter" (or inch, centimetre and so on) gives the declared scale, and requiredextensions names an extension the reader must support. A build item with a p:path= attribute points at a separate model part.

If the root part is not at 3D/3dmodel.model, the second command fails; use unzip -l to find the .model part first. The converter reads the package the same way: it unzips it, parses the model parts, and walks the build items.

That distinction decides the next step. If the archive tests clean but the model uses an extension the reader does not implement, the converter reports a failure rather than a mesh. If the archive test fails, no downstream step helps. Renaming the file to .stl does not convert it either; the bytes are still a ZIP package, and the new extension only hides that from the next program.

What the package check printed

Run on the 20 mm cube fixture, both commands returned a clean package. unzip -t tested three entries and reported no errors, and unzip -l listed three files including 3D/3dmodel.model. The archive was not the failure, so the same file was converted: 12 triangles and a 20 × 20 × 20 mm box in a 684-byte STL.

The fixture is cube-20mm.3mf. The archive test and the conversion ran on 13 November 2026, and the exported STL was read back for triangles and bounds. No print and no slicer import. The test page records the commands and their output.

What a production-split package did here

We tested two packages that declare requiredextensions="p" on 13 November 2026. One keeps a core triangle mesh in the root model; the other moves the mesh into 3D/Objects/object_1.model and references it from a component. PrusaSlicer 2.9.7 opened both. This converter returned a result for the first and an error for the second.

The first row is the quiet failure this page warns about. The converter does not read requiredextensions at all, so it converted a file whose declaration it did not support and said nothing. Here the mesh was complete, so the output was right; on a file where the extension carried the only geometry, the same silence would produce an empty or partial result.

The second row is the loud one, and the message is misleading. “Maximum call stack size exceeded” is an internal error, not a statement that the package is unsupported. PrusaSlicer reads the same file as one 20 mm part, so the bytes are valid; the converter follows the component reference and fails in its own handling. Converting again will fail the same way, because the converter is the part that cannot read the structure.

The signature to check for is in the package, not the error text: unzip -l showing 3D/Objects/*.model entries, and a root model whose build item points at a component. When you see that, the producing slicer is the tool to export an STL from, not this converter. Fixtures: cube-required-p.3mf and cube-production-split.3mf; the test page has both runs.

What the conversion keeps

Open the 3MF to STL converter and drop the file. The browser reader unpacks the archive in the tab, transforms each build item into place, and appends every triangle to one list. The declared 3MF unit is multiplied to millimetres before a binary STL is written. The result panel reports the triangle count, vertex count and bounds in millimetres to two decimals. The bounds are the only field that reveals a unit error.

Nothing is uploaded, and nothing is repaired. If the archive will not unzip, there is no partial STL to download. Conversion is not a recovery tool: a truncated package fails at the same place the slicer failed, and the fix is a fresh copy.

How do you check the scale without trusting the slicer?

Read the Bounds field after conversion and compare it with a dimension you know. A 120 mm bracket should report a longest side near 120.00. If it reports 4.72, the geometry was inches and the declaration was millimetres (120 ÷ 25.4 = 4.72). If it reports 0.12, the geometry was metres (120 ÷ 1000). Both are unit failures with intact triangles.

When the declaration itself is wrong, the Source unit menu adds a correction. Choose Inches (in) → mm to multiply the already-read coordinates by 25.4. Leave it on “Keep the numbers as they are” when the 3MF’s own declaration is correct, or the correction is applied twice. The menu is a multiplier, not a replacement for the declaration.

For a 120 mm bracket, the bounds reading tells you which menu entry to pick:

Picking a correction when the declaration was already right applies the factor a second time, so the error grows rather than shrinks.

When converting is the wrong fix

If the 3MF opens in Bambu Studio or Orca and you need the plate layout, filament assignments or process profile, converting throws those away to solve a problem you do not have. Use a slicer that reads the package.

Convert when the receiver only accepts STL, when the package is readable but the target slicer is older, or when you need one geometry file for a mesh tool. If the converter also refuses the package, the file uses a structure its reader does not implement; open it in the program that wrote it and export STL from there instead.

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

How this page was written: the package structure, unit values and build-item rules come from the published 3MF specifications. The scale examples are arithmetic on the conversion factors. The archive test, package listing and conversion in “What the package check printed” were run on 13 November 2026: unzip printed the output quoted, Chrome converted the fixture, and the exported STL was read back for triangle count and bounds. The two required-extension packages were built with Python’s zipfile, opened in PrusaSlicer 2.9.7, and uploaded to this converter in Chrome on the same day; the split package’s message is the text the result panel showed. No print was made. AI-assisted first draft, checked line by line against the sources and reviewed by the Editor Team.

Sources:

• 3MF Consortium, 3MF Core Specification, v1.4.0, Model and Build sections — accessed 12 November 2026.
• 3MF Consortium, 3MF Production Extension, path attribute and separate model parts — accessed 12 November 2026.
• Bambu Lab, Bambu Studio 3mf Compatibility, sections 2 and 4; records the PrusaSlicer support patch of 21 March 2024 — accessed 12 November 2026.
• Prusa Research, PrusaSlicer 2.7.3 release, released 28 March 2024; pull request 10808, p:path support — accessed 12 November 2026.
• Library of Congress, STL File Format, Binary, 80-byte header and 50 bytes per triangle — accessed 12 November 2026.

Related on this site: the unit factors the converter applies and whether to ask the designer for an STL. See also One shared 3MF, five printers: a makerspace handoff.