PrusaSlicer project 3MF: get the model, not the profile

Run prusa-slicer --export-stl -o part.stl project.3mf and you get the model as one binary STL; the print, filament and printer profiles stay in the project file. The same split applies to the GUI’s File > Export > Export Plate as STL/OBJ.

What PrusaSlicer puts in a project 3MF

Prusa’s knowledge base describes Save Project as a 3MF containing all objects, settings, modifiers and their parameters, a complete snapshot that should produce the same G-code on another computer. The file is the slicer state serialized next to the mesh.

A real Prusa project package reflects that. Alongside 3D/3dmodel.model, it carries its project configuration parts: Metadata/Slic3r_PE.config for the print, filament and printer configuration and Metadata/Slic3r_PE_model.config for per-object and per-volume data. Layer height ranges, custom G-code and wipe-tower state have their own parts. An STL has none of them.

The command line, exactly

prusa-slicer --export-stl -o bracket.stl bracket.3mf

--export-stl is defined in PrusaSlicer’s CLI as “Export the model(s) as STL.” The -o/--output option names the output file; without it, the name is derived from the input. On Windows the console binary is prusa-slicer-console.exe.

The command loads the project, flattens its model into one mesh, and writes that mesh. It does not slice, and it does not write the profile into the STL. If the project has several objects, the export is one file containing all of them, not one file per object.

The output is one file for a specific reason. The CLI calls flatten_to_mesh on the project model, then store_stl. Flattening walks every object, applies its placement transform and merges the triangles into one mesh. One input project gives one STL, not one per object; five projects give five STLs. A plate with five objects becomes one file with five shells.

That is the wrong shape for a per-part print. Use the GUI’s per-object export when the object list matters, or split the plate into separate projects before a batch.

for f in *.3mf; do
  prusa-slicer --export-stl -o "${f%.3mf}.stl" "$f"
done

On Windows, the PowerShell equivalent calls the console binary directly:

Get-ChildItem *.3mf | ForEach-Object {
  prusa-slicer-console.exe --export-stl -o "$($_.BaseName).stl" $_.FullName
}

${f%.3mf} strips the suffix so the output keeps the project name. Without -o, PrusaSlicer derives the name, which is fine for one file and harder to audit across a directory. The output name is the only control the CLI gives you over the file layout.

To see the model statistics before writing anything:

prusa-slicer --info bracket.3mf

The --info flag calls ModelObject::print_info() and prints one block per object. The fields are size_x, size_y, size_z; the six min_ and max_ coordinates; number_of_facets; manifold and, when false, open_edges; number_of_parts; and volume. Record number_of_facets and compare it with the exported STL. The flag exports the model, not a sliced result: no G-code, no supports and no layer preview are produced by either command.

What the export keeps

Geometry with each object’s transform baked in, plus the project’s unit interpretation. Nothing else. Object names, per-object settings, modifier volumes, support enforcers, layer height ranges and the filament and printer selection do not have a field in the binary STL format.

A modifier volume is a slicer instruction, and flattening does not apply it. A support enforcer disappears for the same reason: it was never geometry.

How do you tell a project 3MF from a model 3MF?

List the package:

unzip -l bracket.3mf

A Prusa project has Metadata/Slic3r_PE.config and Metadata/Slic3r_PE_model.config. A plain model 3MF usually has the model part, content types and relationships only. A Bambu project has separate model parts under 3D/Objects/ and no Slic3r_PE files.

That check tells you what you are about to lose before you convert. If the Metadata entries are present, the file is a project and the settings are real data, not a side effect of the name.

What the STL keeps of the profile

Nothing. Layer height, perimeters, infill, supports, temperatures, filament type and printer limits are slicer state. The receiving slicer has to be configured again, and if it is a different slicer, the profile names and values may not map.

A project that produced good G-code on one machine is not a portable print recipe once the geometry is separated.

What happens to object names and profile values?

Object names live in the project’s Metadata/Slic3r_PE_model.config; the STL has no field for them, so a batch of exports is identifiable only by filename. Per-object overrides and modifier parameters have the same fate: they are project data, not geometry.

The converter on this site takes the same geometry-only route. It reads the build items and the declared unit, merges the objects, and writes one STL; the Slic3r_PE parts stay unread, like every other profile part in the package.

The exception is a modifier volume that was used to change geometry rather than to change print behaviour. Inspect the exported mesh if one was present, because the receiving slicer cannot reproduce the modifier from the STL.

Profile values are contextual. Layer height, perimeters, infill, supports, temperatures and cooling depend on nozzle diameter, filament and machine limits. A profile tuned for a 0.4 mm nozzle on one printer can be invalid on another, and the STL carries none of the context needed to judge that. Re-entering values means deciding them again for the new machine.

When is the CLI the wrong tool?

When you need the profile, the per-object settings, or the plate arrangement. Keep the project and open it in PrusaSlicer. The CLI is right when you need geometry for a mesh editor, an STL-only printer, or a batch conversion where the settings are irrelevant.

It is also wrong when the project uses a structure the CLI cannot load. A Bambu Production Extension file is the case that matters: PrusaSlicer 2.7.3, released 28 March 2024, added p:path handling, so earlier builds cannot resolve the split parts. Even 2.7.3 reads the geometry and transforms only; Bambu’s process and filament settings stay in the package.

What to check after the export

Run prusa-slicer --info bracket.3mf and read number_of_facets. Export the same project, then compute (file bytes - 84) / 50 from the STL and compare the result with that facet count. Then count shells: a project with three disjoint objects should export three shells, because flattening merges the triangle lists without unioning them. If two objects overlapped, the shell count drops and the STL contains interior walls.

Open the result in the slicer you will print from and read its stats. A 25.4× or 1000× size error points at a unit mismatch, not at the export. The how-it-works page shows where the unit step sits in this site’s pipeline, and the converter reports the bounds after it runs.

A five-object plate, counted before and after

A model 3MF with five named cubes lists 5 object elements and 60 triangle elements. Converted, it gave 60 triangles and 5 shells, one per disjoint object, in a 3,084-byte STL. Flattening merged the triangle lists without unioning them, so the shell count matched the object count.

The fixture is a model package, not a PrusaSlicer project, so no profile was involved and prusa-slicer was not run. Download plate-five.3mf. We ran the conversion in Chrome on 13 November 2026 and read the STL back for triangles, bounds and shells. PrusaSlicer 2.9.7 opened the saved STL as 60 facets, manifold, 5 parts, 108 × 20 × 20 mm; admesh 0.98.5 reported the same 5 parts and trimesh 4.12.2 read it as watertight. No print was made; the test page lists the readings.

The decision

Converting loses both: a project turned into STL and then queried for its profile has neither the profile nor a project to reopen. The format reference lists the containers that keep settings and the ones that do not.

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

How this page was written: the project contents come from Prusa’s knowledge base and the package layout from PrusaSlicer’s own test files, the CLI flags from PrusaSlicer.cpp, and the --info fields from ModelObject::print_info() in Model.cpp. The converter description is this site’s implementation. The five-object fixture in “A five-object plate, counted before and after” is a model 3MF, not a PrusaSlicer project; it was converted in Chrome on 13 November 2026 and the exported STL was read back for triangles, bounds and shells. No print was run and prusa-slicer was not executed. AI-assisted first draft, checked against the sources and reviewed by the Editor Team.

Sources:

• Prusa Research, Saving projects as 3MF, project contents and snapshot behaviour — accessed 12 November 2026.
• Prusa Research, Export, Export Plate as STL and per-object export — accessed 12 November 2026.
• Prusa Research, PrusaSlicer CLI options, --export-stl, --output and --info handling — accessed 12 November 2026.
• Prusa Research, PrusaSlicer ProcessActions.cpp, flatten_to_mesh and store_stl — accessed 12 November 2026.
• Prusa Research, PrusaSlicer Model.cpp, ModelObject::print_info() fields — accessed 12 November 2026.
• Prusa Research, PrusaSlicer 2.7.3 release, released 28 March 2024, p:path handling — accessed 12 November 2026.
• 3MF Consortium, 3MF Production Extension, separate model parts — accessed 12 November 2026.

Related on this site: what a Bambu Studio project keeps and where the parts go when a plate becomes one STL.