Why the STL is bigger than the 3MF it came from

The STL is bigger because binary STL charges a fixed 50 bytes for every triangle, while 3MF stores each vertex once in a shared table and puts the whole package through Deflate compression. Neither change adds or removes geometry, so the byte difference between the two files is bookkeeping rather than detail.

The package is a ZIP, and that does most of the work

The 3MF Core Specification v1.3.0 requires a 3MF document to use a ZIP archive, and requires the parts inside it to be Deflate-compressed or stored uncompressed. Deflate is therefore a choice the writer makes, part by part, which already explains why file size is a poor fingerprint: the same mesh can leave two applications at very different sizes.

You can see where the bytes go without opening a viewer:

unzip -l part.3mf
unzip -p part.3mf 3D/3dModel.model | wc -c

The first command lists each part’s compressed and uncompressed size. The second prints the raw byte count of the model XML. Running both on the same file tells you how much of the size difference is compression rather than structure, using your file instead of a rule of thumb.

Why is my STL so large?

Binary STL has a fixed record size: an 80-byte header, a 4-byte triangle count, then 50 bytes per triangle — a 12-byte normal, three 12-byte vertices and 2 attribute bytes, as the Binary STL section of Wikipedia’s STL entry lays out. So:

bytes = 84 + (50 × triangles)

Every triangle writes its three vertices in full, and no index connects them. On a closed surface the average vertex sits in six triangles, so the same coordinate is written about six times. Wikipedia states the consequence plainly: mesh connectivity information is discarded because the identity of shared vertices is lost.

3MF works the other way round. Its mesh is a vertex list plus triangles that reference that list by index, so a shared corner is stored once. The vertex count follows from Euler’s formula: for a closed surface, V − E + F = 2 − 2g, where g counts through-holes, and because every edge borders two triangles, E = 3F/2. On a bracket with no through-hole, that reduces to:

V = F/2 + 2

A 200,000-triangle mesh therefore needs about 100,002 vertex records instead of 600,000.

The same mesh, counted three ways

Worked example: a 40 mm UV sphere from THREE.SphereGeometry(20, 100, 1001), which is 200,000 triangles and 101,101 distinct vertex positions. The numbers below were measured by writing that mesh as binary STL and as a minimal 3MF package, in Node, on 12 November 2026. The script is scripts/measure-mesh-sizes.mjs in the site repository, so you can run it and get the same bytes; a real slicer 3MF carries extra metadata and will differ.

The 3,613,212-byte figure is what a binary index-based format would need for the same surface. Deflate earns most of the 3MF’s advantage: it removes repeated element and attribute names, and neighbouring coordinates that share most of their digits. Uncompressed, the model XML is 13.7 MB, larger than the 10.0 MB STL it describes. The archive is what makes the container small.

ASCII STL takes the opposite trade. It writes the same facets as decimal text with no compression at all, which is why a text STL is several times the size of the binary one.

When the 3MF comes out larger

The rule has exceptions, and they matter if you are using size as a proxy for anything.

Small meshes reverse the ratio. The 20 mm cube fixture used in the units post (cube-20mm.3mf) is a 1,043-byte 3MF and a 684-byte STL: at 12 triangles, the ZIP container, content types and model XML cost more than the geometry. From there the STL grows by 50 bytes per triangle while the 3MF pays its package overhead once, so the crossover is a function of triangle count, not a property of either format. Both files are listed on the test page.

A writer may store parts uncompressed, so a 3MF can arrive with no Deflate at all. A project 3MF can also carry package and object thumbnails, a PrintTicket, textures and vendor parts — all listed as document parts in the specification. A single 4096 × 4096 texture is 67,108,864 bytes at 4 bytes per pixel before any compression, nearly seven times the 10,000,084-byte STL above. Per-vertex colour and multi-material assignments split vertices wherever the colour changes, which grows the very vertex table that gives 3MF its advantage. And a 3MF that instances one object twenty times uses components and stores the mesh once; a writer that expands each instance into a full copy gives that advantage back.

Those additions say nothing about the mesh. The 3MF vs STL comparison sets out which of them survive a conversion, and the format reference lists the other containers this tool reads. Neither page answers the question size appears to answer: whether the two files hold the same model.

Does the 3MF win on size alone?

For size alone, on the 200,000-triangle mesh measured above, the Deflate 3MF is 1,564,306 bytes and the binary STL is 10,000,084 — about one-sixth. The same mesh as uncompressed 3MF model XML is 13,743,490 bytes, larger than the STL, so the advantage comes from the compression choice rather than from the container’s name. What settles the format is the handoff: a 3MF keeps the build items, the declared unit and, in a project file, the print settings; an STL keeps triangles at a fixed 50 bytes each. If the receiving tool reads 3MF, converting makes the file larger and drops all three.

Why the converted STL has the size it has

Yes. This converter reads the build items, bakes each transform, converts the declared unit to millimetres and writes one binary STL. Triangles are copied rather than resampled, and the how-it-works page has no decimation or repair stage, so the output size is fixed before the conversion starts: the 200,000-triangle sphere above comes out at exactly 10,000,084 bytes, and a 240,000-triangle model at 12,000,084. The only way to change the STL’s size is to change the source mesh first.

Size cannot tell you whether you have two copies

Binary STL is quantised. Any file with 100,000 triangles is exactly 5,000,084 bytes, whether the triangles describe a machined bracket or a scanned hillside. Two unrelated models with the same triangle count are the same length. And a re-export of the same model can change size without changing shape, because a different tessellation produces a different count.

Count triangles, then measure the bounding box. The converter reports both numbers for the file it reads and the file it writes, so the comparison costs one glance. If the counts match and the boxes agree to a tenth of a millimetre, you are looking at the same model. A mismatch in either is conclusive in the other direction.

For an exact answer, hash the bytes: shasum model.stl proves two files are identical. It cannot prove two different files describe the same shape, since a re-conversion by a different writer, or a re-export from CAD at another tessellation, fails the hash while describing the same part. Count plus box is an equivalence test; the hash is an identity test. They answer different questions, and neither is a duplicate finder on its own.

How do I make an STL file smaller?

1. Re-export from the source CAD at a 0.1 mm chord tolerance instead of 0.05 mm. For the same surface that roughly halves the triangle count; the worst-case deviation from the true surface can grow by up to 0.05 mm, so check the fits that matter against that budget.
2. Decimate at a 0.5 ratio in Blender, then re-check wall thickness and hole diameters. Halving the faces also moves the surface, and thin walls and small holes show the movement first.
3. Drop textures and colour before export when the 3MF is the file under size pressure. An STL cannot carry either, so nothing is lost from the converted file, whose size depends on the triangle count alone at 50 bytes each.

This converter cannot change the tessellation, so it can only write out the triangle count it is given.

What the byte count cannot settle

Two meshes can share a count and a bounding box and differ everywhere in between, so the check catches the obvious failures — wrong file, truncated download, an ASCII STL read as binary — rather than proving sameness.

The conversion merges every build item into one triangle list, so the STL’s count is a sum over the plate. Per-part counts cannot be recovered from it. If per-part provenance matters, split the 3MF before converting instead of trying to unpick the merged mesh afterwards.

An STL carries no checksum, no creator, no timestamp and no geometry identifier; it is triangles plus a 2-byte attribute that most tools ignore. Anything you want to know about where it came from has to be recorded outside the file, before you convert.

By the 3mftostl.io Editor Team, reviewed 14 November 2026. How this was checked: the record sizes come from the published binary STL layout and the 3MF Core Specification’s ZIP packaging and mesh sections. The four sizes in the table were measured by generating one 200,000-triangle sphere as STL and as a minimal 3MF with scripts/measure-mesh-sizes.mjs, and reading the resulting file sizes; nothing in the table is estimated. We converted the 20 mm cube fixture on 13 November 2026; its 1,043-byte 3MF and 684-byte STL are the two small files above. No physical print was made and no slicer import was performed. Drafted with AI assistance and checked against the cited specifications by the team.

Sources:

• 3MF Consortium, 3MF Core Specification, v1.3.0, ZIP packaging and mesh sections — accessed 12 November 2026.
• STL file format, Binary STL section — accessed 12 November 2026.

Related on this site: what an STL cannot carry and what to check when holes and flipped normals appear.