How it works
Updated August 12, 2026 · 7 min read
Filename, File Size or Hash: Which Identifies a Real Duplicate?
Rank common duplicate signals by reliability and learn how to combine them without creating false positives.
Duplicate tools often display the same fields but assign them very different meanings. A filename can help a person recognize a project, while a byte count helps a system reduce comparisons. Neither establishes that the content is the same.
The practical approach is a signal ladder: use cheap fields to locate candidates, then use content-derived evidence to confirm equality. Keep business context—folder, sharing, and history—as a separate decision about retention.
A practical checklist
- 1Normalize case only for search, not for proof.
- 2Group identical byte sizes to create a candidate set.
- 3Compare hashes only when their algorithms are the same.
- 4Require size plus quickXorHash for ClearCopies exact groups.
- 5Use names and paths to decide what to keep, never to upgrade match confidence.
Filename: useful context, weak evidence
Names are editable labels. Sync conflicts append device names, exports add “copy” or numbered suffixes, and generic names such as image001.jpg recur naturally. Conversely, a renamed file can remain byte-identical to its source.
Use filenames for search and reviewer orientation. Do not convert a name match into a deletion recommendation, even if the extensions also match.
File size: fast but incomplete
Byte size is valuable because most unrelated files differ in length. Grouping by size drastically reduces the number of fingerprint comparisons in a large inventory. Yet equal length is possible for unrelated data, especially among generated or fixed-format files.
Size is best treated as a gate: unequal sizes rule out exact equality, while equal sizes justify the stronger comparison. It is not a proof on its own.
Hash: content evidence with boundaries
A supported hash is derived from content and is the strongest metadata signal available for exact matching. OneDrive exposes quickXorHash for applicable files, allowing a no-download comparison. The scanner must retain the algorithm name and handle missing values explicitly.
Even a confirmed content match leaves operational questions. A file item’s location, sharing, ownership, and version history remain distinct, so the final keep choice belongs in a reviewable plan.
- Name explains
- Size filters
- Fingerprint confirms
- Context decides
Limits and risks to check
- — Case-folding names can merge unrelated items in a report.
- — Equal byte size can occur by coincidence.
- — Different hash algorithms cannot be compared directly.
- — Content equality does not preserve shared links when one item is removed.
Official references
Frequently asked questions
What if hashes match but names do not?
The files can still be exact copies. Renaming changes the label, not the file bytes.
What if names and sizes match but no hash is available?
Treat the pair as a review candidate, not a confirmed exact duplicate.
Why does ClearCopies also require size?
It provides an efficient grouping step and a clear, additional consistency condition for the exact-match policy.
Scan first. Decide with evidence.
ClearCopies reads supported cloud-drive metadata and groups exact copies by byte size plus a provider-supplied content fingerprint. Original file bodies are not downloaded for the scan. You review the result and export a plan before any separate write step.