What actually happens after a duplicate is deleted

Deleting a true duplicate on a Mac is usually safe: the other copy keeps the content, and nothing else on the Mac breaks. Three things decide whether that is the whole story. First, whether the "duplicate" was really a separate copy, because on an APFS drive many copies share their storage and deleting one frees almost nothing. Second, whether the folder is synced, because the deletion then travels to every other device. Third, whether anything points at that specific copy, such as a Photos library, a project file or a shortcut. Each of those was checked on a Mac running macOS 27.0.1 on October 8, 2026, with the measurements below.

The short answer, by situation

Before the details, the outcome in the common cases:

What was deleted	What happens to the content	Free space returned	Can it be undone
An independent copy, other copy kept	Safe in the other copy	Full size of the file	Yes, from the Trash until it is emptied
An APFS clone, original kept	Safe in the original	Almost none	Yes, from the Trash
One of two hard links	Safe through the other link	None	Yes, from the Trash
A copy inside iCloud Drive	Deleted on every device	Full size, once synced	Yes, for 30 days on iCloud.com
A duplicate in Photos, merged	One original kept	The extra copy	Yes, for 30 days in Recently Deleted
A file removed with rm	Gone from this location	Full size	No Trash, only a backup

The rows that surprise people are the second and third: a deletion that works perfectly and returns no space. That is not a failed delete, and it is the main thing most duplicate guides leave out.

Why free space sometimes does not change

macOS has used APFS as its default file system since High Sierra, and APFS can make a copy without copying any data. Apple's developer documentation describes it plainly:

A clone is a copy of a file or directory that occupies no additional space on disk.

The same page says the system's standard copy methods automatically create a clone on APFS volumes, and that when one copy is changed, the changes are written elsewhere while both files continue to share the unmodified blocks. So many apps that copy a file on the same drive are creating a clone, and two files that look identical in every way may be one set of blocks with two names.

That was measured directly. A 500 MB test file was created in a folder on the internal drive, then copied three ways. A clone made with cp -c left free space unchanged to within 24 KB, which is ordinary background noise on a busy drive. An ordinary copy with cp used 516,412 KB, the full size. Then each was deleted, with free space read after every step:

• Deleting the clone freed nothing measurable.
• Deleting the full copy freed 512,468 KB.
• Deleting one of two hard links to the original freed nothing.
• Deleting the last remaining name for the original freed 523,664 KB.

A duplicate scanner cannot tell a clone from an independent copy by comparing content, because the content is identical. It lists both, reports that removing one will recover the full size, and the free space counter then does not move. Nothing went wrong. The space was never used twice.

Hard links work the same way for a different reason

A hard link is a second name for the same file. ls -li shows the same inode number for both names, and the link count column shows how many names exist. In the test, the original and its hard link both showed inode 588096381 and a link count of 2. Removing one name dropped the count to 1 and freed nothing. Only when the count reaches zero does the space come back. Backup tools and some package managers use hard links heavily, so duplicates found inside their folders are often of this kind.

A deletion in a synced folder is not a local action

Everything inside iCloud Drive, Dropbox, OneDrive or Google Drive is mirrored. Deleting a duplicate there deletes it from every other Mac, iPhone and iPad signed in to the same account, and from the web copy. That is often exactly what is wanted. The risk is when the "duplicate" in the synced folder is the copy someone else, or another device, actually uses, and the one kept is a local copy that does not sync.

The safety net is on the service side. Apple's iCloud User Guide states that on iCloud.com, files deleted from iCloud Drive and other apps can be recovered within the last 30 days, from Recently Deleted in the iCloud Drive section. Other cloud services keep their own deleted file lists with their own time limits, so it is worth checking the relevant help page before a large clean-up rather than after.

A practical rule follows from this. When duplicates sit on both sides of a sync boundary, one in a synced folder and one outside it, delete the one outside the synced folder unless there is a specific reason not to. That deletion stays on one Mac.

Online only files add one more case. A file that shows a cloud icon and has not been downloaded takes no local space at all. Deleting it locally returns nothing to the Mac's free space, and still removes it from the cloud.

Duplicates inside an app's library

Photos libraries, Music libraries and similar are packages: they look like single files in Finder, but hold many files the app tracks by its own database. Duplicate scanners that look inside them will find many matches. Deleting files from inside a library with Finder or a scanner leaves the app's database pointing at things that no longer exist, which shows up as blank thumbnails or missing items.

Photos has its own tool for this, and Apple's Photos User Guide describes it. Duplicates appear automatically in the Duplicates collection under Utilities in the sidebar, which may take some time to fill on a large library while Photos analyses it. The steps:

1. Open Photos and click Duplicates below Utilities in the sidebar. If it is not shown, hold the pointer over Utilities and click the button that appears.
2. If iCloud Shared Photo Library is in use, choose Both Libraries from the Library pop-up menu in the toolbar.
3. Select the duplicates to merge. Command A selects all of them.
4. Click Merge Items, then confirm in the dialog.

Apple states that one original appears where the selected duplicates were, and that the deleted duplicates go to Recently Deleted, where they can be recovered within 30 days. That is a much safer route than deleting files inside the library package.

The same principle applies to any project that refers to files by path. A video edit, a design file with linked images, or a website folder may point at one specific copy of an image. Deleting that copy, even when an identical one exists elsewhere, breaks the link. The content survives, but the project needs to be pointed at the remaining copy.

Symbolic links fail the same way and quietly. A symbolic link that pointed at the deleted copy stays in place but leads nowhere. After a clean-up, this command lists every broken symbolic link under the current folder, so they can be repointed or removed:

$ find . -type l ! -exec test -e {} \; -print

How long the undo lasts depends on the route

How a duplicate is removed decides how long it can be brought back.

Finder's Move to Trash keeps the file in the Trash until the Trash is emptied. Finder's settings include an option, under Advanced, to remove items from the Trash after 30 days. If that is on, the window is 30 days. If it is off, items stay until the Trash is emptied by hand. Free space is only returned when the file leaves the Trash.

rm in Terminal skips the Trash. The file's name is removed immediately and, if it was the last name and not shared with a clone, the space is released. Recovery then depends on a backup.

Time Machine keeps the most recent hourly backups, then daily and weekly ones, as space allows. A duplicate deleted today can be restored from an earlier backup if the drive was connected when that backup ran. Before a large duplicate clean-up, starting a backup with Back Up Now from the Time Machine menu gives a known restore point.

Duplicate cleaning apps vary. Some move items to the Trash, some delete directly, and some offer a review list. The setting is usually in the app's preferences and is worth reading before the first run.

Checking before deleting, from the command line

Three short checks answer most of the questions above for a specific pair of files.

Whether the contents really match:

$ shasum -a 256 "Report.pdf" "Report copy.pdf"

Identical hashes mean identical content. Different hashes mean the files only look alike, often a newer and an older version with the same name.

Whether the two names are the same file:

$ ls -li "Report.pdf" "Report copy.pdf"

The same number in the first column means a hard link. The number after the permissions is the link count.

Whether a folder lives inside a synced location: the path tells it. Files under ~/Library/Mobile Documents are in iCloud Drive, and folders under ~/Library/CloudStorage belong to providers such as Dropbox, OneDrive and Google Drive.

There is no simple command that says whether two files are APFS clones of each other. The practical test is the one used above: note free space with df -h ., delete one copy, empty the Trash, and read it again. If nothing changed, the files were sharing blocks.

Doing it inside the folder, not in a separate window

The checks above are each one line, but they run in a specific folder, and the friction is getting a Terminal window into that folder and then back to the files. A file manager with a built-in terminal removes that step, since the terminal opens in the folder already on screen. Some also include a command to find duplicate files in the current folder, which keeps the scan limited to one place instead of the whole drive, where libraries and synced folders make the results harder to judge. The Features page shows that layout. The Mac side is free with no time limit, according to the Pricing page, so it can be tried on one folder without changing anything else.

Whatever tool is used, scanning one folder at a time is the habit that avoids most of the problems in this guide. Library packages, synced folders and backup folders each need their own approach, and a whole-drive scan mixes all three into one list.

What to change first

Before the next clean-up, run shasum and ls -li on one suspected pair to see which kind of duplicate it is, and remove copies outside synced folders first. For photos, use Duplicates in Photos rather than a file scanner. For a terminal that opens in the folder being cleaned, see Atriens.