Converting a 3MF to STL keeps every triangle where it was and drops everything else. The second half often shows up only at the slicer, when a plate of five parts arrives as one grey lump and the colour assignments are gone.
An STL is a list of triangles. The binary STL layout is an 80-byte header, a 4-byte triangle count, then 50 bytes per triangle: a normal vector, three vertex coordinates, and a 2-byte attribute field. There is no place in that structure for a name, a material, a colour, a unit, or a slicer profile.
Parts stop being parts
A 3MF describes a build: one or more objects, each with its own mesh and transform, assembled into a plate. STL describes nothing but triangles in a shared coordinate space. After conversion, the five objects on a plate are five groups of triangles that happen to sit near each other.
The immediate cost is that you can no longer select a part. You cannot move it, delete it, scale it, or assign it a different infill. If you need the parts back, you have to cut them apart by connectivity or re-import the 3MF.
A quick check before converting: open the 3MF in its slicer and count the objects in the plate list. Write that number down. After conversion, if your downstream tool reports separate shells, compare the count. If it reports one, the merge is confirmed and the part structure is gone.
A five-box plate with three base materials and a declared unit of millimetre was generated for this page and written twice: once as a 3MF with five build items, once as the merged binary STL that the narrowing produces. The readings are from the files, not from a slicer:
| Reading | 3MF before | STL after |
|---|---|---|
| Objects | 5 build items, named Part 1 to Part 5 | 1 merged triangle list |
| Connected shells | 5 | 5 |
| Material slots | 3 base materials, one per box group | 0 |
| Declared unit | millimetre | none; coordinates already in mm |
| Triangles | 60 | 60 |
| Bounding box | 110 × 50 × 20 mm | 110 × 50 × 20 mm |
| Bytes | 1,489 | 3,084 |
The script is scripts/measure-mesh-sizes.mjs in the site repository; run it with --plate to regenerate both files. The byte counts move with the metadata a writer adds, but the two structural readings do not: the STL has no object list and no material slots, and the names Part 1 to Part 5 exist only in the 3MF.
The five parts are still five disconnected shells, so a mesh report can count them even though the converter no longer keeps them apart. What the STL cannot say is which shell was object 1, which was object 2, or that they were ever named.
How do you split an STL back into parts?
Split by connectivity, and weld first. Binary STL writes every triangle’s three vertices in full, so an importer that does not merge coincident points sees the measured plate as 60 separate islands rather than the five shells that are actually there. After welding, each build item is one closed shell, and a connectivity split reproduces the five boxes with the plate’s 60 triangles and its 110 × 50 × 20 mm bounding box unchanged. What it cannot recover is the mapping: an object that was itself two disconnected shells splits into two pieces, and no shell carries a name, so compare the count against the object count you recorded before converting.
A split by colour cannot run on the STL at all. Colour exists in the 3MF’s base-material assignments; the STL’s only candidate carrier is the 2-byte attribute, with its unstandardised VisCAM and Magics packings that most slicers ignore. A tool offering “split by color” on an STL is therefore either reading that attribute on a guess or asking you to paint the areas by hand.
Names and metadata have no slot either
A 3MF can carry a name per object, plus document metadata such as Title, Designer and Description. STL has one 80-byte header, and most writers put an ASCII credit line there rather than anything you typed; this converter writes “Binary STL written in the browser”. Open any binary STL in a text editor and read the first 80 bytes: if your part name is not there, the name was dropped, not stored.
Where do the colour areas go?
3MF stores colour as a base material with per-object or per-triangle assignment, and multi-material printers rely on exactly that. STL has no colour definition at all, only that 2-byte attribute.
There are two non-standard uses of the attribute worth knowing, because they explain why some files look like they have colour. VisCAM and SolidView pack 15-bit RGB there; Materialise Magics uses a different packing. A few viewers honour one convention, most slicers ignore the field entirely, and no convention is part of any STL specification. If you convert a coloured 3MF and the STL opens grey in one program and beige in another, neither program is wrong: both are guessing at an unstandardised field.
The practical version: decide before conversion whether colour matters. If it does, the 3MF is the file to send to the slicer. Painting a multicolour model after the fact means re-assigning materials in the slicer anyway, and you would be doing that work either way.
What the two-colour test file produced
We converted a fixture with two cubes assigned red and blue base materials; the STL was 1,284 bytes. The whole file is the 84-byte header, the 4-byte triangle count and 24 triangles at 50 bytes each; there is no colour block, because the container has nowhere to put one.
| Reading | Value |
|---|---|
| Objects and colours | 2 (red, blue) |
| Triangles | 24 |
| STL bytes | 1,284 (84 + 24 × 50) |
| Connected shells | 2 |
The fixture is downloadable as two-colours.3mf; opening it in the converter reproduces the counts above, and the test page records the run.
Do slicer settings survive the conversion?
A slicer project 3MF can carry the process, filament and printer profile alongside the geometry. That is the whole reason Bambu Studio and PrusaSlicer ship project files as 3MF rather than as a model plus a separate settings file.
STL carries none of it. Layer height, infill, supports, temperatures, plate arrangement: all of it has to be set again in whatever tool receives the file. The format has done this since 1987, when it was introduced to move geometry between stereolithography machines; settings were never part of what it moved.
Re-creating a project from the STL means re-entering every profile value the 3MF carried: layer height, perimeters, infill, supports, temperatures and plate layout. On a typical profile that is a dozen or more fields, and it only works if you still know them. Note them, or keep the project file.
Units are a declaration, not a conversion
3MF states its unit in the model XML, and the values are valid microns, millimetres, centimetres, inches, feet or metres. A reader that honours the declaration knows how big the object is without guessing.
STL has no unit field. Every slicer assumes millimetres because that is the convention; nothing in an STL declares it. It breaks in one direction: an object modelled in inches and written to STL as raw numbers lands 25.4 times too small, with geometry perfectly intact and nothing in the file to warn anyone.
The converter applies the declared 3MF unit and writes millimetre coordinates into the STL, so the numbers are already correct. That only works when the source unit is correct. If the 3MF says millimetres and the designer modelled in inches, the error passes straight through.
Check it against something you know before printing: the machine’s build volume, a 20 mm calibration cube, or the thread pitch of a known bolt.
A size check you can do on the file
Binary STL has a fixed record size, which makes the triangle count verifiable without opening the model:
triangles = (file size in bytes − 84) ÷ 50
A 12 MB STL therefore holds about 240,000 triangles. If the number your slicer reports is far off, the file is probably ASCII STL, which stores the same data as text and is roughly five times larger, or it is truncated. Either way, the count is a cheap way to confirm you converted the file you meant to.
Then check the bounding box. The converter writes millimetres, so a 200 mm object should measure near 200 in whatever reads the STL. A number that is 25.4× off points at the unit, and a number that is 1000× off points at a metre/millimetre mismatch upstream.
When should you not convert?
Do not convert a 3MF to STL when the 3MF still does its job. If your slicer reads 3MF, the container gives you parts, colour and settings for free, and downgrading throws them away for no benefit. The conversion is worth doing when the receiving tool is STL-only: an older slicer, a printer’s web interface, a mesh editor with a narrow importer, or a service that asks for STL by policy.
If the parts matter after conversion, split before you convert. Selecting one object in the 3MF and exporting it on its own is faster than cutting a merged mesh apart later, although the STL still drops the object name.
By the 3mftostl.io Editor Team · Reviewed 14 November 2026
Sources:
- 3MF Consortium, 3MF Core Specification, v1.3.0, Package and Model sections — accessed 12 November 2026.
- STL file format, file structure and the non-standard colour extensions — accessed 12 November 2026.
- Prusa Research, PrusaSlicer wiki: 3MF files, project 3MF versus model 3MF — accessed 12 November 2026.
How this page was made: the byte counts come from the binary STL record layout; the object, material, triangle and byte readings come from the five-box 3MF and merged STL written by scripts/measure-mesh-sizes.mjs --plate; the colour-extension notes follow the STL format description. The two-colour fixture in “What the two-colour test file produced” was converted in Chrome on 13 November 2026, and its exported STL was read back: 1,284 bytes is 84 + 24 × 50, with no colour record. No physical print was made and no slicer import was performed. Drafted with AI assistance and reviewed by the Editor Team, which runs the converter.
Related on this site: the full 3MF vs STL comparison, which container carries what, why the STL is larger than the 3MF, and what to check when holes and flipped normals show up.
Convert your own 3MF
Drop a 3MF file and get one STL in millimetres. Runs in this tab; nothing is uploaded and no account is needed.