Compare file hashes, not names. Two files with the same name and size can differ, and two identical files often have different names — a hash reads the actual bytes and produces a short fingerprint, so matching fingerprints means matching content. Anything else is a guess.
Duplicates accumulate without anyone deciding to make them: a download clicked twice, a folder copied “just in case”, photos imported from a phone that had already been imported. The files are easy to find and easy to get wrong, and getting it wrong means deleting the only copy of something.
Why name and size are not enough
The obvious approach is to look for files sharing a name and a size. It is fast, and it is wrong in both directions.
It reports duplicates that are not duplicates. Two different photographs from the same camera can share a file name and land within bytes of each other in size. Two exports of a report on different days are the same name and near enough the same length, and one of them is out of date.
It also misses real duplicates. The same file saved as invoice.pdf, invoice(1).pdf and Scan_20260114.pdf is three names for identical content, and nothing about the names says so.
What a hash does
A hash function reads every byte of a file and produces a short fixed-length string — a fingerprint. Change a single byte anywhere and the fingerprint changes completely.
That gives you the property you actually want. Two files with the same SHA-256 hash are, for every practical purpose, the same file: same bytes, whatever they are named, wherever they sit, whatever the timestamps say. Different hashes mean genuinely different content, even if everything else about them matches.
Sometimes the question is narrower: is this download the same as the one I already have? Generate a hash for each file and compare the two strings. Identical means identical; anything else means not.
The same technique verifies a download against a checksum published by whoever distributed it. A match confirms the file arrived complete and unaltered, which is worth doing for installers and disk images regardless of duplicates.
Which copy to keep
If the contents are identical, the file itself gives you no reason to prefer one. Decide on location and context instead.
Keep the one in the folder where it belongs, and delete the copy in Downloads or on the desktop. Location is the only thing that differs, so location should decide.
Keep the one with the more descriptive name. Between Scan_20260114.pdf and 2026 tax return.pdf, only one will make sense in two years.
Prefer the older file when timestamps differ but content does not. The newer one is usually the copy.
Be careful with anything referenced by something else. A duplicate image inside a project folder may be linked from a document, and deleting it breaks the link even though an identical file exists elsewhere.
Where the dates matter to the decision, file metadata shows created and modified times alongside the size.
What identical does not mean
Byte-for-byte identical is a strict test, and its strictness cuts both ways.
Two exports of the same photograph at different quality settings are different files. Both are kept, and one is probably redundant — but a hash cannot tell you that.
A document saved twice by the same word processor may differ, because some formats record a timestamp or an editing session identifier inside the file.
A file and its compressed version are entirely different, obviously, but people are sometimes surprised that renaming a file does not change its hash at all. The name is not part of the content.
The trouble with cloud duplicate finders
To find duplicates across your files, a tool must read your files. A service that does this on a server must first receive them — which means uploading the entire set being checked, including whatever is in it, in order to be told that two of them are the same.
That is an unusually poor trade. The result is a small list of matches; the cost is a full copy of a folder that probably contains documents, photographs and correspondence, transferred to somebody else’s storage to produce it.
Hashing needs no server at all. Your browser can read a file and compute its fingerprint locally, at whatever speed your machine manages, and compare fingerprints without any file leaving the device. The comparison is exact, and nothing is sent anywhere — see what actually happens when you upload a file for why that distinction is worth insisting on.