How duplicate detection works

Updated Sep 11, 2026 · 6 min read

Content hashing groups exact copies, a geometry tier catches re-exports, whole folders that hold the same pack collapse into one card, and every group recommends which copy to keep.

Duplicate detection runs when you ask for it: open the Duplicates view and hit Analyze. It is kept out of scanning on purpose, because hashing a terabyte-scale library means reading every byte and that should happen when you choose, not unannounced in the background. The pass gives each model a content hash, a fingerprint derived from the file's actual bytes. Two files with the same hash are the same model, regardless of their names or which folders they live in. That works inside ZIP, RAR, 7Z and TAR/TGZ archives too: a copy buried in a downloaded archive groups with the loose file next to it. And the Duplicates view counts only what belongs there: models, archives, and laser/CNC cut files (SVG and xTool projects) matched by exact bytes. Companion files like photos and PDFs are indexed alongside your models but never reported as duplicates, so a preview render repeated across fifty folders can't bury the real findings.

Re-exports: the geometry tier

Rhino duplicate detection is content-only: identical file bytes match, but no geometry fingerprint is generated. For other supported models, exact matches are only the first tier. STL, OBJ, 3MF, FBX and STEP models also get a geometry fingerprint derived from the mesh itself, so the same model re-exported under a different name still groups even though the file bytes differ, as long as the export didn't move it. STL, OBJ, 3MF and FBX are fingerprinted from the mesh they were authored with, so a plain conversion between them matches too; STEP describes CAD surfaces rather than a mesh, so its fingerprint comes from the triangulation Meshory generates and matches other STEP files. The format support matrix lists this per format, alongside thumbnails, 3D preview and archive support. And moved, rotated, rescaled, or re-tessellated near-copies surface separately as likely duplicates for you to review: they never join bulk cleanup unless you look at a group and confirm it. A slicer project of the same model usually lands in that queue, because saving a project typically re-centers the mesh. When every model in a group has exactly the same triangles and only its position changed, Needs review usually labels the group “Same triangles, moved”, so a slicer project saved from an STL is quick to spot. It still waits for your confirmation.

Whole folders that hold the same pack

There is a third level above the file. When two or more folders hold exactly the same set of models, Meshory says so once instead of reporting every file inside them: a pack sold with the same models in four folders becomes a single card naming those four folders, not two hundred file-level matches. Only the models are compared, so the READMEs, preview renders and PDFs can differ freely. The card lists what differs rather than treating it as a mismatch. Because it compares content, a folder-level match works across drives: the same pack on your NAS and on your desktop groups, and the card marks the copy it recommends keeping, preferring a local copy over one on a NAS and a deliberately filed path over a dump folder. The filter bar has a “Whole-folder matches only” switch for when that is the only kind of finding you want to see.

That's how the Duplicates view groups copies together: the dragon you downloaded three times under three names becomes a single entry listing every copy and where it lives, so you can see the redundancy instead of tripping over it. Your library itself is untouched; each file stays right where it is.

One pack inside another, or the same pack with extra files

Whole-folder matches need the two sets of models to be identical, and two shapes slip past that. A bundle of 70 models can sit entirely inside a bundle of 80, and nothing about the smaller one is new. A pack downloaded twice from sites that inject their own filler model into every upload has two copies that differ by a single file they never wanted. Meshory reports both as folder overlaps: one card per pair, saying either that all of one folder's models are in the other, or how many the two share.

These cards carry no recommended keeper, because there is no safe general answer: in the injected-junk shape the bigger folder is usually the junked copy, and recommending it would steer you into keeping the junk. Each side states its own consequence instead. A side reads “Trashing loses nothing” only when every model in it exists somewhere else, no companion file would go with it, and every source holding one of those copies answered; otherwise it says what would be lost, and the list of models only that side holds shows where each one lives, such as “also in 37 other folders”. That figure is how an injected file gives itself away. Trashing a side names every model that would be lost and asks you to agree to that exact list, and if the list changes while the dialog is open, the trash is refused rather than carried out against what you read.

Cleaning up, with a recommended keeper

Detection only ever reads, and it sorts before you do: every group marks one copy as Recommended and says why. Recommended goes to the copy in your organized folder rather than a downloads pile, the oldest copy, or the copy inside an archive, which can't be trashed on its own anyway. Keep recommended selects the rest of the group in one click, and Auto-select recommended everywhere applies the same rule across all groups at once; likely duplicates sitting in Needs review are never included. Cleaning up stays a step you take: choose Move to Trash and the selected copies go to your system Trash (the Recycle Bin on Windows), where they can be restored if you change your mind, and copies on network drives, which have no Trash to restore from, get a warning first. See Moving models to the Trash for what that touches.

New to Meshory? The duplicate STL finder page shows how detection fits into cleaning up a real library.