Why did deleting duplicates not free any space?

Three causes account for almost all of it. The Trash has not been emptied, so the space is still reserved. The files were APFS clones or hard links, so only one copy of the data ever existed. Or a snapshot is still holding the deleted data. Compare the figure in System Settings before and after a batch to see which applies.

Is a free duplicate finder more reliable than hashing files by hand?

They use the same method. Both compare content hashes, so the matches are the same matches. The difference is presentation and control. An app displays groups side by side and handles photos and music libraries; the command line lets you set a size floor, exclude paths, and repeat the exact query later.

What should be checked when System Data is the largest category?

System Data is defined as everything that does not fit another category, so it is a symptom rather than a location. On a machine used for development, the usual contents are build output, container images, and downloaded dependencies. All three regenerate from configuration files, which makes them a much better first target than photo duplicates.

Is it safe to delete files with `rm` in the terminal?

`rm` bypasses the Trash and cannot be undone, so treat it as the last step rather than the first. Write candidates to a text file and read it before acting, or move them to a dated quarantine folder and wait two weeks. When a wildcard is involved, run the command with `echo` in front first to see exactly what it expands to.

Telling which files are safe to delete

The startup disk is down to single digit gigabytes, and the obvious move is to hunt for duplicates. So a scanner gets installed, it runs for twenty minutes, and it returns four thousand candidates. Now the problem is worse than before, because the list is long and nothing on it is obviously safe to remove. Anyone searching for how to find duplicate files mac free of extra cost has usually reached this point. The missing piece is not a better scanner. It is a rule for deciding, and a clear picture of where the space actually went.

Three different things get called clutter

Treating the delete list as one pile is what stalls the job. It is three different categories with three different costs to evaluate.

Copies are the same bytes sitting in more than one place. They come from photo exports, saved mail attachments, and project folders duplicated before a risky edit.

Regenerable artifacts are files that can be rebuilt from something else that is still on disk. Build output, downloaded dependencies, package manager caches, rendered video exports. Deleting these requires no judgement at all, because a wrong call costs one command and some waiting.

Unreferenced material is finished work. Assets from a project that shipped last year, backups of a phone that no longer exists, source files in a format nothing opens anymore. These can be cut by date and project name without opening a single one.

The order matters. Duplicates are the category people start with, and they are usually the smallest win per hour spent. On a Mac with a development environment on it, build artifacts and container images routinely run to tens of gigabytes and can be regenerated from a config file that is a few kilobytes. Clearing those first changes the storage picture before any duplicate has been examined.

A duplicate does not always cost twice the space

This is where duplicate scanners mislead. Two files with identical contents do not necessarily occupy two files worth of disk.

APFS, the file system on current Macs, supports cloning. Duplicating a file in Finder, or copying it with cp -c, creates a second name that points at the same blocks. Only the parts that later diverge get written for real. A scanner comparing contents will flag that pair as a duplicate, correctly, and deleting one side will free approximately nothing.

Hard links behave the same way. Some backup schemes and Time Machine local snapshots create references that look like independent files in a listing.

Then there is the most common reason of all for space not coming back, which Apple states directly.

Empty your Trash. When you move a file to the Trash, its storage space doesn't become available until you empty the Trash. Source: support.apple.com

Snapshots add another layer, holding deleted data for a period after the delete. That is what the purgeable figure in the free space readout refers to.

The practical rule: a duplicate scanner's total is a count, not a forecast of recovered space. Check the storage figure before and after a batch of deletions and let the difference decide whether the approach is working.

Read the storage breakdown before installing anything

Open the Apple menu, choose System Settings, click General in the sidebar, then Storage. Categories with a More Info button open into a browsable list.

The category that confuses everyone is System Data.

The category named System Data (or Other) is a general category that measures the storage space used by all Apple and third-party files that don't belong to any more specific category. Source: support.apple.com

So it is not a place. It is everything that had nowhere else to go: logs, caches, virtual machine images, container data, and application support directories. When System Data is the largest bar on the chart, photo duplicates are not the problem and no duplicate scanner will touch it.

Read the top three categories and work only on those. If Documents dominates, duplicate detection and large file hunting are the right tools. If System Data dominates, the development environment is the target. Skipping this step is how people spend an evening reviewing four thousand candidates in the category that was never large.

Offloading to iCloud is a legitimate option, but not a free one. Apple lists iCloud storage as starting at 50GB for $0.99 a month in the United States, with regional pricing elsewhere.

What macOS already finds without help

For specific file types, the built-in tools are enough.

Photos, in macOS Ventura 13 and later, keeps a Duplicates album. It groups exact copies as well as versions that differ only in export size, and merging a group keeps the copy with the highest resolution and the most metadata. When Photos is high in the storage breakdown, this is the first place to look.

Music can list duplicate library entries from its File menu, matching on song and artist. Holding Option while choosing the command narrows it to exact duplicates rather than different recordings of the same title.

Finder smart folders save a query as a folder. Conditions such as larger than 100 MB and last opened more than a year ago can be combined and kept for reuse. What a smart folder cannot do is compare contents. Name, size, and date are the limit, which is why it finds suspicious groups but never proves two files are identical.

The Downloads folder needs no query at all. Installer disk images, expanded archives sitting beside the archive they came from, and numbered re-downloads accumulate there. Sort by date and work from the oldest end.

Counting duplicates from the terminal

The standard tools cover both halves of the job, and running them first tells you whether a dedicated app is worth installing.

For large files, find ~ -type f -size +500M sets a floor. For directories, du -sh */ inside a folder, piped through sort -h, ranks the subfolders by size on one screen.

For identical contents, hash the candidates. find . -type f -size +1M -exec shasum {} + produces a hash for each file, and sorting on the hash column and passing it to uniq -d leaves only the groups that repeat. The size floor is the important part. Including every small file makes the hashing slow and surfaces matches whose removal frees nothing.

The index-backed search is worth knowing as well.

The mdfind command consults the central metadata store and returns a list of files that match the given metadata query. The query can be a string or a query expression. Source: the mdfind(1) manual page included with macOS

Results come back immediately because nothing is walked, and -onlyin limits the scope to one directory. The trade is coverage: anything excluded from the index, such as folders in the Search Privacy list or a volume with indexing disabled, will not appear. Use find when completeness matters and mdfind when speed does.

Do not chain the search straight into a delete. Write the candidate list to a text file, read it, then act. Removing a file with rm does not put it in the Trash and there is nothing to undo.

Free tools, and what each one is actually for

Tool	Cost	Good at	Not for
dupeGuru	Free, open source	Content and filename matching, with music and picture modes	Seeing where space went
GrandPerspective	Free, open source	Showing usage as proportional blocks so large files stand out	Deciding if two files match
OmniDiskSweeper	Free	Walking down a folder tree in size order	Deciding if two files match
`find` with `shasum`	Built in	Precise filters and scripted repeats	Reviewing results comfortably

The choice follows from the question being asked, not from the feature list. How many copies exist is one question. Where did the space go is a different one, and the storage breakdown already said which of the two applies.

With Homebrew installed, jdupes and rmlint add options such as replacing duplicates with hard links and maintaining exclusion rules, which suits a task repeated monthly. Automated deletion belongs at the end of this process, once the rule for deciding is settled. Automating an unsettled rule only deletes the wrong things faster.

The places to leave alone

Deletion accidents cluster in the same few directories.

The Library folder inside the home directory holds application settings, keys, licences, and mail data. Large files in there rarely have names that explain themselves, and that is the reason to leave them. The Photos library is a package, and opening it to delete individual files inside will corrupt the library rather than shrink it. A .git directory is the project history, not a cache.

Some things are genuinely safe. Xcode's DerivedData holds build intermediates that regenerate on the next build. A node_modules directory restores from a lockfile. Homebrew's downloads clear with brew cleanup, and docker system df reports what container images and volumes are consuming before anything is removed. One test covers all of them: can this be rebuilt from something that is still here.

For anything that fails that test but still looks disposable, quarantine instead of deleting. Move it to a dated folder, leave it two weeks, and delete it if nothing broke. That does not help when the disk is full today, but for routine cleanup it is the safest sequence available.

External drives deserve a separate pass. A duplicate scanner pointed at the internal disk will report a file as unique when the only other copy lives on a drive that happens to be unmounted, and the same scan run with the drive attached will report the pair as redundant. Neither result is wrong; the scope changed. Decide in advance which volume is the archive and which is the working copy, and delete only from the working side. The same caution applies to synced folders, where removing a local file propagates the removal to every other device sharing that account.

Where the time actually goes

Cleanup drags on because of the round trip, not the detection.

The shape is easy to see once counted. A hash comparison returns a candidate group. Confirming what those files are means switching to Finder, pasting a path, and looking. Then back to the terminal for the next group. Each round trip is a few seconds, and three hundred candidates turn that into an afternoon. Going the other direction costs the same: a large file spotted in Finder has to have its path copied before any command can touch it.

This is the argument for a file manager with a built-in terminal. When the listing and the prompt share one working directory, the path copy and the window switch disappear, and a candidate can be inspected and acted on in the same place. The Features page describes how that layout works, and Compared with other file managers sets it against dual pane and terminal centric tools that solve a different part of the problem.

What to change first

Read the storage breakdown and clear the regenerable artifacts before touching a single duplicate. That one reordering recovers more space than any scanner on a machine with development tools installed. If the remaining friction is switching windows to confirm each candidate, that is a layout problem rather than a search problem, and Atriens is built around that gap.