Duplicate files on a Mac: which copy actually stays

Most advice about duplicate files starts at the wrong end. It offers a scanner, a list of matches, and a select all button, which leaves the hardest question untouched: given two files that really are identical, which one is the copy and which one is the thing other work points at. Getting that wrong is worse than keeping both, because a duplicate costs disk space while a wrong deletion costs a rebuilt document, a broken link in a project, or a photo that only existed in one place. The useful sequence runs the other way. Decide what counts as a match, work out where the copies came from, and only then run anything.

Four ways two files can be the same

The word duplicate covers four different relationships, and every tool picks one of them. Knowing which one is in use explains both the false matches and the misses.

Match rule	Catches	Wrongly catches or misses
Same filename	Copies scattered across folders	Every index.html, README.md, and IMG_0001.JPG in unrelated projects
Same name and size	Renamed folder copies	Misses anything renamed on the way, such as report (1).pdf
Byte identical content	True redundancy, regardless of name	Misses re-encoded or re-exported versions of the same content
Visually or audibly similar	Photos re-imported at a different size or quality	Flags deliberate variants, such as a cropped version kept on purpose

Name matching is the fastest and the least trustworthy. A search for repeated names across a development folder returns hundreds of results that are all correct and all meaningless, because build systems and frameworks depend on files having the same name in different places.

Content matching by hash is the only rule that supports a confident delete, because two files with the same hash really are interchangeable. Its blind spot is exports. A photo saved at two quality settings, a video re-encoded for upload, and a document exported to PDF twice are all the same content to a person and completely different bytes to a hash.

Similarity matching sits at the other extreme. It is the only rule that recognises the same photograph saved at two resolutions, and it is also the only rule that cannot be verified by looking at the result. Two images that a similarity engine calls a pair might be the same shot at different quality, or two frames taken a second apart that were both kept on purpose. That distinction is invisible in a list of filenames and obvious in a preview, which is why similarity results have to be reviewed as pictures rather than as rows.

Pick the rule before opening a tool, because the rule determines what the resulting list means. A list built on names is a list of things to look at. A list built on hashes is a list of things that can be acted on. A list built on similarity is a list of things to look at side by side, and treating it like the second kind is how deliberately kept variants disappear.

The five things on a Mac that quietly make copies

Duplicates are not random. On a working Mac they come from a short list of mechanisms, and each one leaves a recognisable trace.

The first is the browser. Downloading the same file twice does not overwrite it. The second copy becomes invoice-2.pdf or invoice (1).pdf depending on the browser, which means the Downloads folder accumulates numbered chains of the same document over months.

The second is cloud sync conflicts. When the same file is edited on two devices before syncing, the client keeps both and renames one. Dropbox produces a name containing the phrase "conflicted copy" and a date. iCloud Drive and other clients use their own patterns. These are the highest value duplicates to resolve, because one of the two contains work that the other does not, and neither is safe to delete blindly.

The third is a version chain made by hand. A document saved as plan.docx, then plan-v2.docx, then plan-final.docx, then plan-final-2.docx is not a set of duplicates in the hash sense, since the contents differ. It behaves like one, because only the last file matters and the others are kept out of caution.

The fourth is media import. Importing the same memory card or the same shared album twice creates a second set of images with new filenames and identical content.

The fifth is the defensive folder copy. Before a risky reorganisation, a whole directory gets duplicated as Projects copy or Desktop old. This one generates the largest volume of duplicates by size, and it is also the easiest to resolve, because the entire tree either matched at the time of copying or did not.

Sorting a match list by mechanism rather than by size turns a thousand rows into five decisions. The mechanism is usually readable from the path alone. Numbered chains sit in Downloads, conflict copies sit in a synced folder, version chains sit next to the working document, media imports sit in a dated import folder, and defensive copies sit one level above the folder they were copied from. Scanning the parent directories of a match list, rather than the filenames, identifies which of the five is responsible in under a minute, and that answer decides how the whole group gets handled rather than how one file does.

The newer timestamp usually marks the copy

The instinct when facing two identical files is to keep the newer one. On macOS that instinct is backwards more often than not, and it is worth demonstrating rather than asserting.

A plain cp gives the new file a fresh modification time. The original keeps its own. So after copying a file that was last edited in January, the copy carries today's date and the original still shows January. Sorting by date and keeping the newest keeps the copy and deletes the file that has been sitting in the project folder all along.

$ touch -t 202601010000 a.txt
$ cp a.txt c.txt
$ cp -p a.txt d.txt
$ stat -f "%N mtime=%Sm" a.txt c.txt d.txt
a.txt mtime=Jan  1 00:00:00 2026
c.txt mtime=Sep  4 23:41:54 2026
d.txt mtime=Jan  1 00:00:00 2026

The -p flag preserves the original time, which is why files that arrived through rsync -a or a restored backup keep their real dates while files dragged in Finder or copied with a bare cp do not. Two identical files with different dates therefore say nothing reliable about which one is the source.

The same applies to downloads. A file downloaded today from an archive is stamped today regardless of when it was written, so a re-downloaded copy always looks newer than the version already stored.

The one case where the timestamp does carry information is the conflict copy, where the client writes the date into the filename itself. That date is the moment of the conflict, not the moment of the edit, so it identifies which side to inspect rather than which side to keep.

Build a list that can be reviewed, not a button that deletes

The safe shape of this work is an inventory first. Hashing the candidates and grouping by hash produces something that can be read, sorted, and argued with before anything is removed.

find . -type f -size +1M -exec shasum -a 256 {} + | sort > /tmp/hashes.txt
awk '{ if ($1 == prev) print; prev = $1 }' /tmp/hashes.txt

The second line prints only the files whose hash repeats the previous line, which is the set of second and later copies within each group. Writing it to a file matters more than the exact command, because a list in a text file can be sorted by parent directory, which is the view that makes the decision obvious. Ten identical files spread across ten folders is a puzzle. Ten identical files where nine live under one folder named Desktop old is a single decision.

The size floor is doing real work here. Hashing every small file is slow and fills the output with matches whose removal frees nothing measurable, such as empty configuration files and identical icons.

For photographs, the built in path is better than anything a shell can do, because it compares images rather than bytes.

Deleted duplicates appear in Recently Deleted, where you can recover them within 30 days or permanently delete them. Source: support.apple.com

The Duplicates collection under Utilities in the Photos sidebar merges rather than deletes, keeping the higher quality version and its metadata, and the recovery window makes it reversible. Nothing in the shell handles a library package safely, so this is the one category where the built in tool is the correct tool.

Rules that decide which copy stays

Once a group of identical files is on screen, the decision is about position, not about the file. Four rules resolve almost every case.

The copy something else points at wins

If one of the copies sits inside a project that references it by path, inside a repository, or inside a folder that is shared with other people, that copy stays. The others are unreferenced by definition, since the reference can only point at one path.

The copy in a managed location beats the copy in an inbox

Downloads, Desktop, and Documents root are inboxes. Anything that reached a real destination has already been filed once, and refiling it a second time is work that was already done.

Conflict copies get opened, never bulk deleted

A file whose name contains a conflict marker holds edits that exist nowhere else. The correct action is to open both, merge by hand, and then remove the loser. This is the one group where a bulk operation is genuinely dangerous.

Whole folder copies get resolved as folders

Comparing Projects and Projects copy file by file wastes an afternoon. Comparing the two trees as trees, and asking only whether the copy contains anything the original does not, turns it into one question with a yes or no answer.

Closing the source so the list stays short

Deleting duplicates without changing what makes them is a task that repeats every quarter. Three changes remove most of the inflow.

Set the browser to ask where each download goes, or point downloads at a folder that gets emptied weekly. The numbered chains only accumulate because the default location is never cleared.

Resolve sync conflicts on the day they appear rather than at cleanup time. A conflict copy discovered three months later cannot be merged, because nobody remembers which side had the correct paragraph. Most clients can surface conflicts in a list, and checking that list weekly is a few seconds.

Replace defensive folder copies with something that can be undone. A copy made before a risky change is a snapshot with no expiry date, and it survives precisely because deleting it feels risky later. Time Machine already keeps that snapshot, which makes the manual copy redundant on the day it is made.

The wider point is that file cleanup competes with the work it interrupts. A folder view that shows sizes, hashes, and a shell in the same place removes the switching that turns a five minute audit into an afternoon. That is a different category of tool from a duplicate scanner, and the differences are set out on the Compared with other file managers page, with day to day behaviour under Features.

What to change first

Run the hash listing once against the largest project folder and sort the output by parent directory rather than by size. The folders that repeat will name the mechanism, and fixing the mechanism is what stops the list from coming back. If the audit keeps stalling because the terminal and the folder view are separate windows, a single window that holds both, such as Atriens, removes that friction before the next pass.