.3MF File Format – Package and parts

Versions of the core specification

The core namespace has stayed http://schemas.microsoft.com/3dmanufacturing/core/2015/02 throughout; versions of the core and of each extension are told apart by the namespaces declared on the <model> element.

ZIP container

• The package is a ZIP archive following PKWARE’s APPNOTE.
• Each file is either Deflated (method 8) or stored (method 0); no other method is allowed.
• Consumers must read ZIP64 and the streaming (data descriptor) form. Producers should write plain ZIP unless the data needs ZIP64. A streaming producer may reserve an extra field with ID 0x9999 in each local header and later overwrite it with a ZIP64 extra field if one turns out to be needed.
• The file’s own media type is model/3mf.

Byte by byte, the ZIP layer is described on the ZIP pages.

Parts

Only one 3D payload is primary: the 3D Model part that the package’s StartPart relationship points to. All content needed to make the objects must be inside the package; external references are not allowed unless an extension allows them. There may be only one relationship of a given type from one part to another. A producer that writes a PrintTicket, StartPart or Thumbnail relationship must include its target part, and a consumer must report an error if it is missing.

Content types and relationship types

[Content_Types].xml at the root of the ZIP gives the content type of every part, by extension (Default) or by part name (Override).

Relationships live in _rels/.rels for the package and in _rels/name.rels beside each part for that part.

<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Target="/3D/3dmodel.model" Id="rel-1"
    Type="http://schemas.microsoft.com/3dmanufacturing/2013/01/3dmodel"/>
  <Relationship Target="/Metadata/thumbnail.png" Id="rel0"
    Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/thumbnail"/>
  <Relationship Target="/Metadata/MustPreservePart.txt" Id="rel-2"
    Type="http://schemas.openxmlformats.org/package/2006/relationships/mustpreserve"/>
</Relationships>

Part names

Part names are absolute (they start with /), must not be empty and must not start with a full stop. The recommended names are:

Thumbnails are usually /Metadata/thumbnail.png, by custom rather than by rule.

File name conventions

Since version 1.4.0 the specification recommends a double extension that says what a 3MF file is for. These names are reserved for their purpose:

Plain .3mf is still what most programs write.

Thumbnails

Thumbnails are JPEG or PNG, always reached through a Thumbnail relationship: from the package for the package thumbnail, from the 3D Model part for an object’s thumbnail (named by the object’s thumbnail attribute).

XML rules

• UTF-8 only; an encoding declaration may name no other encoding.
• No DTDs; consumers should treat one as an error.
• Content must be valid against the published XSD schemas; elements and attributes from undeclared namespaces may appear only where the schema allows any.
• No xml:space; whitespace may be repeated wherever one space is allowed.
• Numbers use the en-US form: a full stop as decimal separator.
• xml:lang may give the language; und when unknown.
• Consumers must ignore elements and attributes from namespaces they do not support, unless the model lists that namespace as required.

Signatures and protection

Digital signatures follow OPC. A signature on the 3D Model part should cover that part, the parts it references and their relationships, and may also cover the package thumbnail, signature origin and core properties. The model XML is canonicalised (XML C14N) before signing or checking. Content protection also follows OPC; a consumer allowed to decrypt content must not save it unprotected without the protection authority’s approval. The Secure Content extension defines 3MF’s own encryption.

Vendor parts

Slicers store their own project data as custom parts. PrusaSlicer, for example, declares the namespace http://schemas.slic3r.org/3mf/2017/06 (prefix slic3rpe) on the model and writes extra files in Metadata/, such as Metadata/Slic3r_facets_annotation.json. These private parts are not part of the 3MF specification and are not described here.