Duplicate Image Finder

Exact hashing vs. perceptual hashing: two different questions

Finding duplicates is really two questions, and they need two different tools. 'Are these the same file?' is answered by a cryptographic hash like SHA-256: feed in the bytes, get a fixed fingerprint, and identical bytes always produce identical fingerprints. Change a single bit — re-save, recompress, edit one pixel — and the hash changes completely. That's perfect for catching literal clones (you saved the same download twice) and useless for catching look-alikes, because to SHA-256 a JPEG and its 95%-quality re-export are unrelated strangers.

'Do these look the same?' is answered by a perceptual hash — here a 64-bit difference hash (dHash). It shrinks the image to a tiny grayscale grid and encodes the brightness gradient between adjacent cells, producing a fingerprint that captures the image's structure rather than its exact bytes. Two visually similar images get similar dHashes even when their files differ entirely. You compare two dHashes by Hamming distance — the count of differing bits — so 'similar enough' becomes a number you can threshold. This tool runs both hashes on every image, because each catches cases the other can't.

Reading the Hamming-distance threshold

The strictness setting is a Hamming-distance ceiling on the perceptual hash, and picking it well is the difference between a clean result and a noisy one. Lower is stricter:

dHash distance is a similarity score, not a verdict. Above ~10, always eyeball each group before deleting — the tool shows duplicates side by side for exactly this reason.

Why filenames lie — and what near-duplicates really are

Filenames are the worst possible signal for duplicate detection, and relying on them is how libraries fill up with redundant copies. The same photo arrives as IMG_4821.JPG from the camera, photo.jpg after a download, Screenshot 2026-06-19.png after an edit, and image (1).jpg after a messaging app strips its metadata — four names, one picture. Meanwhile two genuinely different photos can share a name the instant two cameras both emit DSC_0001.JPG. Size and timestamp are nearly as unreliable: recompression changes the size, and copying rewrites the timestamp. Only the pixels tell the truth, which is exactly why hash-based detection looks at content and ignores the name entirely.

'Near-duplicate' is the category filenames can never surface: same image, different bytes. A WhatsApp-compressed copy, a lightly cropped version, an Instagram re-save, a screenshot of the original — all look identical to you and all have different file hashes. Perceptual hashing is the only practical way to collapse those into one group. After review, export the deduplicated set and keep the highest-quality member of each group, not whichever copy happened to sort first.

What perceptual hashing will and won't catch

It's worth being honest about the edges. dHash is excellent at recompressions, quality changes, modest crops, and resizes — the everyday ways one image becomes many files. It is deliberately not a reverse-image search and not an object recogniser: a hard rotation, a heavy crop that changes the composition, a mirror flip, or a strong colour-grade can shift the hash enough to break the match, and two different photos of the same landmark are similar to your brain but structurally distinct to a 64-bit gradient hash. That's the right trade for a deduplicator — classic perceptual hashing is deterministic, runs in milliseconds per image, and is what production tools rely on, whereas an AI similarity model would add tens of megabytes of weights and worse repeatability to solve a problem hashing already solves. When you need to catch flips and large crops too, loosen the threshold and accept that you'll be reviewing more groups by hand.