Technical deep-dive

Hash-based vs. geometry-aware duplicate detection for 3D print files

Updated Aug 9, 2026 · 8 min read

Yes: duplicate 3MF and STL files can be detected by hash, but only the exact copies. A content hash fingerprints a file's bytes, so it groups renamed copies perfectly and misses re-exports completely: saving the same mesh out again produces a file with different bytes, which a hash treats as a brand-new model. Catching those takes a second tier, a fingerprint derived from the geometry itself. This page explains what each tier catches, what each one misses, and how Meshory runs both with a review queue in between, so nothing gets cleaned up on a machine's word alone.

Why filename matching fails for 3D models

Filename matching fails because duplicate 3D models almost never share a filename, and files that do share one are often different models entirely. Copies pile up through perfectly ordinary habits: the Patreon pack you downloaded a second time just to recover one missing file, the miniature you saved from a creator's Thingiverse listing and again from their Printables listing, the half-finished reorganization that left a sorted copy of every model sitting beside the unsorted original, the USB stick of favorites that got dumped back onto the main drive.

Every one of those events changes the name or the location while leaving the model identical, which is exactly the case filename comparison can't see. And the reverse failure is just as common: exporters churn out generic names like body.stl and output_v3.stl, so matching on names would happily group files that have nothing in common. Names carry no reliable signal in either direction.

That's why every serious approach is content-based duplicate detection: compare what is in the files, not what they're called. For 3D models, "what is in the file" has two useful layers: the bytes, and the mesh those bytes describe. Each layer catches a different kind of duplicate.

What a content hash catches and what it misses

A content hash catches every byte-identical copy of a file, no matter what the copy is named or where it lives. The hash is a compact fingerprint computed from the file's actual bytes: two files with the same fingerprint have the same contents, so renamed copies, copies in forgotten folders, copies on other drives and copies on NAS mounts all collapse into one group. Fingerprints are also cheap to compare, which is what makes exact detection practical across tens of thousands of files.

What a hash misses is everything that rewrites the file. A re-exported model is, to a hash, a brand-new file. The mesh is the same, the bytes are not. Re-saving through a slicer or CAD tool re-serializes every vertex; exporting a binary STL as ASCII (or the reverse) changes every byte; converting between formats, say STL to 3MF or OBJ to STL, produces a different container around the same shape. A single differing byte means a different fingerprint, so none of these copies group.

This is the honest limit of hash-only duplicate finders, including the checksum matching most library tools rely on: they find your re-downloads, and they are structurally blind to your re-exports.

What geometry-aware detection adds

Geometry-aware detection compares the mesh itself rather than the bytes that happen to encode it, so the same model saved as different files still groups. In Meshory, STL, OBJ and 3MF models get a geometry fingerprint derived from the mesh in addition to the content hash. With it, a re-export under a different name, or even a different format, lands in the same duplicate group as the original despite sharing no bytes with it.

There's a third category between "identical" and "different": near-duplicate 3D models. A copy that was rotated, rescaled or re-tessellated is probably the same model. But probably isn't certainty, and a deliberately modified variant deserves to survive a cleanup. Meshory surfaces these separately as likely duplicates for you to review: they are flagged, never silently merged into the groups you'd bulk-clean.

How Meshory runs both tiers

Meshory runs both tiers as part of every scan: each model it indexes gets a content hash, and STL, OBJ and 3MF models get the geometry fingerprint on top. Fingerprinting rides along with indexing rather than being a separate chore. The engine was hardened against a 3.3 TB, 39,000-model library before launch, and a library that size indexes in just under a minute. The result is the duplicate STL finder: one Duplicates view where the dragon you downloaded three times under three names becomes a single entry listing every copy and where it lives.

The two certain tiers, identical bytes and identical geometry, are the only ones bulk actions ever touch. Near-copies stay quarantined in the likely-duplicates queue until you look at a group and confirm it, so a group you clean up really is the same model. And the view stays honest in the other direction too: only models and archives are ever reported as duplicates, so the preview render a creator repeated across fifty folders can't bury the real findings.

• Nothing is deleted for you. Meshory groups the copies and shows every location; it never deletes, moves or renames anything on its own. Cleanup is a decision you make with full information.
• Everything runs locally. Scanning, hashing and grouping happen on your machine: no upload, no cloud, no account.
• NAS sources are handled gently. Fingerprinting on network mounts runs at a NAS-friendly pace and only reads files whose size matches another file's, and you can pause it from the Duplicates view or switch it off entirely.

The full mechanics are part of geometry-aware duplicate detection in every Meshory license: both certain tiers, the review queue, and what bulk actions can and can't touch.

Duplicates hiding inside ZIP, RAR and 7Z archives

Some of your duplicate models aren't loose files at all. They're still inside the archives they arrived in. A Patreon bundle you extracted but kept, a ZIP downloaded twice into different folders, the same creator pack living once as an archive and once unpacked: to a tool that only scans loose files, all of that redundancy is invisible.

Meshory treats ZIP, RAR and 7Z archives as part of the library: models inside them are indexed as first-class entries, so a copy buried in a downloaded ZIP groups with the loose file sitting next to it. You don't extract anything to find out what's duplicated: the archive's contents join the same Duplicates view as everything else.

So which one do you need?

You need both tiers, because a real library contains both kinds of duplicate: re-downloads, the exact copies a hash catches, and re-exports, where the mesh is the same but the bytes differ and only geometry matching catches them. A hash-only pass leaves the second kind behind, which is precisely the kind that filename habits like _fixed and _v2 create the most of.

One neighboring distinction is worth keeping straight: if your downloaded packs are broken rather than redundant, with holes, flipped normals or non-manifold edges, that's a mesh-repair job, not a duplicate job. The difference is spelled out in repair vs. duplicate cleanup. And deduplication itself is step one of a bigger project; the complete system is in the guide to organize your STL library.