Should you store print settings in 3MF or STL?

STL stores triangles. That is the whole format: a surface mesh with no units, no colors, no materials, and nowhere to put a layer height. So the choice is not really between two places to keep your settings, it is between keeping them in a 3MF project and not keeping them at all.

3MF is a zipped container that can carry the model plus everything around it. When a slicer saves a project as 3MF, it writes a snapshot of the session: objects and their positions, the settings in use, modifiers, and painted supports or seams. Prusa’s documentation describes it as a complete snapshot that should produce the same G-code when reopened on another computer.

Which format to keep the geometry in

The settings question has a second question hiding behind it, which is what the archive copy of a model should be. Those have different answers, and this one is less about features than about which file you will still be able to open and trust.

Take 3MF when you are the one exporting, and keep whatever the designer shipped when you are downloading. Converting a file you were given is a lossy re-export you cannot undo, so a folder holding the original STL plus your own project 3MF beats a folder holding a converted copy of something you no longer have.

Three differences drive that. The first is units. An STL is a list of coordinates with no declaration of what they mean, so millimeters are a convention rather than a fact, which is where the imported-at-one-twentyfifth-scale class of problem comes from. A 3MF carries a unit attribute on the model element, valid values running from micron to meter and defaulting to millimeter, so the file states its own scale.

The second is size, and the gap is larger than most people expect because it is structural rather than just compression. STL repeats every vertex once per triangle that touches it, while 3MF stores vertices once and has triangles reference them by index. Taking the standard 3DBenchy as a concrete case: the binary STL is 11,285,384 bytes for 225,706 triangles built from only 112,569 distinct vertices. Repacking those same triangles as an indexed mesh in a zipped 3MF container gives 2,085,337 bytes, about 18 percent of the original. A real slicer project 3MF is larger than that, since it also carries settings and a thumbnail, but the geometry itself genuinely does shrink by roughly this much. ASCII STL is the worst case in the other direction and there is no reason to keep files in it.

The third is what the format can express at all. STL is triangles. 3MF handles multiple objects in one file, colors, materials, and the transforms that place parts on a plate, which is why a multi-part assembly survives as one 3MF and becomes a naming problem as a set of STLs.

The case for STL is compatibility, and it is not a small one. Every mesh tool, repair utility, and print service built in the last thirty years reads it, while 3MF support in older software and in some CAD and mesh utilities is patchier than slicer support suggests. If a file has to go somewhere you do not control, STL is still the format that arrives intact.

When a 3MF project is worth saving

Save one when the settings took work. A part with painted supports, per-object modifiers, a specific plate arrangement, or a profile you tuned over three attempts is worth ten seconds of “save project as” because reproducing it from memory later costs an hour.

Skip it for the simple case. A single object printed at your default profile does not need a project file, and a folder full of near-identical 3MFs is its own kind of mess. The rule that holds up: if reopening the file would save you a decision, save a project.

There is a second use worth naming, which is sharing. A 3MF sent to someone with the same slicer carries the setup with it, so “print this at these settings” is one file rather than a paragraph of instructions and a screenshot.

What a 3MF project does not do for you

The settings inside a project 3MF are written by and for one slicer. Geometry moves between slicers reliably; the configuration around it may not, since each slicer writes its own settings block in its own vocabulary. Treat a project file as tied to the tool that made it, and check rather than assume when you open one somewhere else.

It also has nothing to do with what your printer receives. The printer gets G-code, and the settings that produced it are frozen there at slice time. A project 3MF is the input side of the same story: it lets you slice again with the same settings, but it is not a record of what you actually printed.

That distinction decides where each file belongs. Keep the mesh or project as the source, keep the sliced output as revisions of it, and let the outcome attach to the slice rather than to the project.

Where a library reads settings from

PrintStash parses settings out of G-code and BGCODE, not out of 3MF projects. What lands on a revision is what the slicer wrote into the file’s header: slicer name and version, printer model, nozzle diameter, layer height, infill, wall count, supports, temperatures, estimated time, and filament use.

For 3MF itself, the library stores the file, renders the mesh, and extracts the embedded thumbnail: the thumbnail.png the specification defines, or the plate images OrcaSlicer and Bambu Studio write. It does not read the embedded slicer configuration, so a project file will not populate the settings fields the way a sliced file does.

The practical consequence is worth stating plainly, because people expect the opposite: uploading a 3MF project gives you geometry, a preview, and a source file. Uploading the G-code that came out of it gives you the settings record. Most workflows want both on the same model, which is the shape a revision history already has.

A layout that works

1. Keep the source geometry, whether that is STL, 3MF, OBJ, or STEP, as the model.
2. Save a project 3MF alongside it when the setup was non-trivial, and treat it as the recipe.
3. Attach each sliced G-code as a revision, with a label saying why it exists.
4. Record outcomes on the revisions, since that is the only layer that knows how the print went.
5. Reslice from the project rather than from memory when you need a variant.

Questions that come up

Can an STL store print settings at all?

No. The format defines a list of triangles and nothing else: no units, no material, no color, no metadata block for a slicer to write into. Some people encode settings in the filename to compensate, which works until the string runs out of room or the file gets renamed. If you want settings stored with the model, the file has to be a 3MF project, and if you want a record of settings that were actually used, that lives in the G-code.

Should I download 3MF instead of STL from model sites?

When the designer offers one, yes, because a project 3MF tells you what they printed: orientation, supports, and the profile that worked. That is often the difference between a first print that succeeds and three that do not. The caveat is that the settings only apply cleanly in the slicer that produced them and on a comparable machine, so treat a stranger’s profile as a starting point rather than a guarantee.

Does a 3MF project replace G-code revision history?

No, they answer different questions. A project stores the inputs, so you can slice again the same way. A G-code revision stores the output and what it was made with, which is the only thing you can attach a print outcome to. Keeping only projects means you can reproduce a slice but cannot say which one printed well; keeping only G-code means you can say what worked but have to rebuild the setup to change anything. Keep both against the same model.

Will a library extract settings from my 3MF files?

Not in PrintStash. A 3MF is stored, rendered, and given a preview from the thumbnail embedded in the archive, which for OrcaSlicer and Bambu Studio includes their plate images, but the slicer configuration inside it is not parsed. Settings come from sliced G-code or BGCODE. If a model in your library shows no settings, check whether you uploaded the project rather than the slice.

Is 3MF always better than STL?

For printing, mostly yes: it is smaller, unambiguous about units, and can carry color, materials, and settings. For interchange with older tools, STL is still the format everything reads, which is why it persists. The honest position is that STL remains a fine container for pure geometry, and 3MF is the one to reach for whenever anything beyond geometry matters.

Sources

• Saving projects as 3MF in the Prusa Knowledge Base for what a project file contains and how it differs from an STL export. Checked August 12, 2026.
• The 3MF core specification for the unit attribute and its allowed values, and for the indexed vertex and triangle mesh structure. Checked August 19, 2026.
• Size figures measured against the standard 3DBenchy binary STL, repacked as an indexed mesh in a deflate-compressed 3MF container. Measured August 19, 2026.
• PrintStash user guide for which formats are parsed for settings and which are previewed only.

For what happens after the slice, tracking G-code revisions covers the revision record, and automatically organizing a library covers what the parsed metadata does once it is stored.