Convert STL to 3MF

3D Systems published STL in 1987 for a machine that took triangles and nothing else, and the format is honest about that: no units, no colour, no materials, no names, no parts, no vertex sharing, no metadata. Everything the printing world added afterwards — scale conventions, multi-part plates, per-object settings — lives outside the file and has to be reconstructed by whoever opens it.

3MF, published in 2015, put those things inside the file. Units are declared, objects are separate, colour and materials have a place, and the whole thing is an OPC package with a manifest rather than a raw byte stream. Converting an STL gains you the packaging and the units immediately. It does not conjure colour or parts that were never recorded, and no converter can.

STL stores every triangle as three independent vertices with no indexing whatsoever. A cube — twelve triangles — arrives as thirty-six vertex records where eight distinct positions would do. That is not a quirk of a particular exporter; it is the format.

The conversion welds them: coordinates are rounded to six decimal places to form a key, and every triangle corner at the same position collapses to one shared vertex. Six places is far below any printable tolerance and far above the last-bit disagreement two adjacent triangles routinely have in a float. What comes out is a real indexed surface, which is why a manifold check on the 3MF gives a useful answer where the same check on the STL reports every edge as a boundary.

The 3MF resources section will contain a single object and the build section a single item. That is not a simplification — an STL genuinely has no way to say that its triangles form three separate bodies, so there is nothing to divide on, and inventing a division by connectivity analysis would be a modelling decision rather than a conversion.

If your STL does contain several disconnected shells, every slicer has a Split to Parts or Split to Objects command that finds them by connectivity after import. Doing it there is the same operation with a preview attached. If you want the parts recorded in the file itself, the source needs to be a format that had them — an OBJ with groups, or a glTF with several meshes.

The 3MF is written with unit="millimeter" in its model element and the coordinates are passed through untouched. Strictly, the converter is asserting a unit the source never declared. In practice this is the least dangerous case of that assertion anywhere in the 3D matrix, because the printing world has treated STL numbers as millimetres for thirty years and every slicer imports them that way.

The gain is that the assumption stops being an assumption. A 3MF that says millimetre imports at the same size into PrusaSlicer, Cura, Bambu Studio and Microsoft 3D Builder without any of them applying a house convention. The one case to watch is an STL exported from CAD in inches, which was already going to import at 1/25th size and will now do so with a unit declaration backing it up.

Each triangle record in a binary STL ends with a two-byte attribute field the specification leaves unused. Two conventions grew into that gap — one from VisCAM and SolidView, one from Materialise Magics — encoding a fifteen-bit RGB colour per triangle. Neither is part of STL, and no two tools agree on which of them a given file uses.

The reader here takes the twelve bytes of face normal and the thirty-six bytes of vertex data from each fifty-byte record and never touches the last two. So a coloured STL converts to a colourless 3MF, silently. 3MF has a proper colour model and could hold the result; guessing which of two incompatible conventions produced a bit pattern is not a guess a converter should make on your behalf.

By arithmetic, not by the leading word. The obvious test — does the file start with "solid"? — is wrong, because the eighty-byte header of a binary STL can contain anything and several writers put "solid" in it. Files that fail that way appear to parse and produce nothing.

A binary STL is exactly 84 + 50n bytes for the triangle count written in its header: eighty bytes of header, four for the count, then fifty per triangle. Nothing else lands on that number by coincidence. If the length matches, the file is read as binary; otherwise the text is scanned for vertex lines. Both paths reach the same welded model.

The STL side is exact and easy to check: a 100,000-triangle model is 5,000,084 bytes, always, whatever the shape. That predictability is the one thing the format is genuinely good at, and it is also why STL files are so much larger than the geometry in them warrants — three quarters of those bytes are repeated coordinates.

The 3MF stores each welded vertex once as an XML element and each triangle as three integer references, then deflates the lot inside the ZIP package. Verbose markup compresses extremely well, and the vertex sharing has already removed most of the redundancy before compression starts. The result is model-dependent, and for typical printable geometry it is comfortably smaller than the STL it came from.

Three entries in a ZIP: [Content_Types].xml declaring the content types for .model and .rels, _rels/.rels with a single relationship pointing at the model, and 3D/3dmodel.model holding the geometry in the 3MF core namespace. That structure is what makes it an OPC package, the same convention DOCX and XLSX use.

It is a model file rather than a project file. There are no print settings, no filament assignments, no plate arrangement and no thumbnail, because those are per-slicer extensions rather than part of the geometry. Your slicer will apply the profile you have selected and let you save its own richer 3MF afterwards.

Holes stay holes, flipped triangles stay flipped, self-intersections stay, internal walls stay, and zero-area slivers stay. Nothing here inspects the topology beyond merging coincident vertices, and a mesh that failed a slicer's check as an STL will fail it as a 3MF with the same message.

The one thing that does change is the class of error caused by unshared vertices, which is every STL by construction. After welding, a surface that is geometrically closed is also topologically closed, so repair tools and manifold checks in Blender, Meshmixer or your slicer are working on the mesh you meant rather than on thirty-six thousand loose triangles. That alone makes a repair session shorter.