Find large files in a Mac: where the space went

The search for how to find large files in mac storage almost always starts with a warning dialog. The instinct is to list the biggest files and start deleting. That instinct is usually wrong, because on a working Mac the space is rarely held by one enormous file. It is held by a directory containing tens of thousands of small ones, and no file-by-file list will ever surface it.

Folders first, files second

Two facts make the file-level list a poor starting point.

The first is arithmetic. A project directory can occupy fourteen gigabytes while containing no single file above one gigabyte. Every entry in it is a few kilobytes. A list sorted by file size will not show that directory at all, and deleting the largest individual files in it would reclaim almost nothing.

The second is judgement. A filename on its own carries no information about whether it is safe to delete. A path does. Knowing that something sits inside a cache directory, an export folder, or a documents folder answers the question that a size figure cannot.

So the working order is top-down. Identify the largest directory on the volume, descend into its largest child, and repeat. Each step follows the branch with the most weight, which means the number of steps stays small even on a deep tree. This is a fundamentally different activity from scanning a list and guessing, and it ends at a location rather than at a filename.

The free space number disagrees with itself

Before hunting, establish how much space is actually missing. This is where the first trap sits.

df -h /

On a modern macOS install that reports the read-only system volume. On one machine checked while writing this, it showed thirteen gigabytes used, which reads as a nearly empty disk. The documents, applications and caches live on a separate volume.

df -h /System/Volumes/Data

At the same moment, that command reported ninety-eight percent full. APFS splits the startup disk into several volumes that share one pool of free space. Reading only the root path leads to a conclusion that is off by orders of magnitude.

There is a second layer, called purgeable space. Time Machine local snapshots, caches and other reclaimable data are counted as used but will be released automatically when something needs room. This is the usual reason the Finder info window and a Terminal command disagree. Purgeable space does not need a person to chase it. The goal is to find what will not be released on its own.

Walking down with du

Directory totals come from du. Printing everything is unreadable, so constrain both depth and threshold.

du -h -d 1 -t 500M ~/ | sort -h

-d 1 sums one level down. -t 500M suppresses anything below five hundred megabytes. sort -h orders output that mixes K, M and G suffixes, because the macOS build of sort understands human-readable numbers. Take the largest line, make it the new starting path, and run the same command again.

Adjust the threshold as the descent goes deeper. Five hundred megabytes is right at the top of a home folder; one hundred works better a few levels down, where it exposes branching that a high threshold flattens. Running without any threshold both floods the screen and slows the summation itself.

One detail about what du reports: it measures space occupied on disk, not the sum of file contents. In a directory of many tiny files, per-file allocation overhead makes the disk figure larger than the logical total. -A switches to apparent size, but when the goal is reclaiming space, the default is the number that matters.

Unreadable directories produce one error line each. Redirect them with 2>/dev/null when the output becomes hard to read, keeping in mind that those directories are then missing from the total. Add -x to stay on one volume, otherwise a mounted external disk or network share gets summed too, and the command stops returning.

Now the file-level pass

Once the responsible directory is identified, switch to files.

find ~/Movies -type f -size +1G -exec du -h {} + | sort -h

-size requires an explicit unit: c for bytes, k, M, G for the obvious ones. Without a suffix the number means 512-byte blocks, which produces results that look arbitrary. Ending with -exec du -h {} + batches the matches into few invocations rather than one per file.

The indexed route is faster when it applies.

mdfind "kMDItemFSSize > 1073741824"

That queries the Spotlight index for files above one gigabyte and returns immediately. It only knows about indexed locations, so volumes with indexing disabled and excluded directories are invisible to it. Use mdfind for speed and find for completeness.

In Finder, the size filter is reachable without any command. Open a search window, reveal the search criteria row, add a rule, and choose file size from the other attributes list. Set the scope to the whole Mac rather than the current folder, since the scope defaults to wherever the search started.

Large items that must not be deleted

A size-sorted list mixes three very different categories, and only one of them is safe to act on directly.

Time Machine local snapshots accumulate on the internal disk even when the backup destination is not connected. They do not appear in Finder and they do not appear in a file listing. To confirm they exist, run tmutil listlocalsnapshots against the startup volume.

Application working files are the second category. Export and render operations create intermediate data that nobody consciously saved, and it stays.

The file that was supposed to appear here did not show up in the list, possibly because it was too large. Source: syobochim.hatenablog.com

That is the practical reason to check from the command line as well as from the built-in storage screen. The two do not always agree, and the built-in view is designed around categories rather than paths.

The third category is library bundles. A photo or video library looks like one huge file but is a container holding many real files plus the metadata that makes them findable. Deleting it from outside destroys the catalogue along with the contents. Reducing its size means opening the application, removing items there, and emptying its own recently deleted area.

Application caches sit in between. Deleting them works and nothing breaks, but they are rebuilt on next launch, so the space comes back only until the next session. Lasting reductions come from data that is not regenerated.

The shape of directories that keep growing

Across different machines, the same handful of locations dominate. Knowing the list shortens the descent.

The downloads folder holds installers and disk images long after they served their purpose. Export destinations accumulate generations of the same video or image, because exports get repeated after every edit. Development directories carry dependencies and build output, which is regenerable but numerous enough that deletion itself takes time. Mail keeps local copies of attachments. Virtual machine and container disk images reach tens of gigabytes each and do not shrink when files inside them are deleted.

Duplicates deserve a separate mention, because they hide inside these same locations rather than forming a category of their own. The same video exported twice under slightly different names, a folder copied as a manual backup before an edit, an archive expanded next to the archive it came from. Size-sorted output makes them easy to spot, since identical figures on adjacent lines are rarely a coincidence.

Only some of these repay deletion. Export folders and downloads do. Development directories come back on the next build. Virtual machine images need compacting or recreating from the outside, not cleaning from the inside. Recognising the category from the path is what turns a size figure into a decision.

The built-in storage screen and what it leaves out

macOS has its own storage view under general settings, and it answers a different question from the one a size hunt asks. It groups usage by category, such as applications, documents, messages and system data, and it offers actions for some of those categories.

That framing is useful for a first look and misleading as a second one. Categories do not map onto directories, so a large figure under a generic heading gives no path to investigate. The catch-all category in particular absorbs caches, logs, virtual machine images, snapshots and anything the classifier could not place, which means it grows for reasons the screen cannot explain.

The command line answers the question the screen cannot: which directory, at which path, holds the weight. The two are complementary rather than competing. Use the settings screen to confirm the scale of the problem and whether a managed category is responsible, then use du to find the actual location. Doing it the other way round, treating a category total as a target for deletion, produces guesses.

One more difference is worth noting. The settings screen shows figures after purgeable space has been accounted for, while a command reports allocation as it stands. A gap of several gigabytes between the two is normal and does not indicate a fault.

An order of operations before deleting

Deletion has no undo outside the trash, so fix the sequence in advance.

Identify what uses the data first, by reading the parent directories rather than the filename. Then move rather than delete: relocate the item, keep working for a few days, and see whether anything breaks. Only then remove it. If the same data reappears, the useful change is not another deletion but stopping the process that creates it, which usually means an export destination or an automatic save location.

Skipping this sequence guarantees a repeat of the whole exercise in a month. Disk pressure is a rate problem, not a one-time cleanup problem. To measure the rate, run the same du command on two different days and compare.

du -h -d 2 -t 100M ~/ 2>/dev/null | sort -h > ~/Desktop/usage-2026-09-26.txt

Saving the output under a dated name makes the next run comparable. The directory that grew is the one worth changing settings for.

Counting the window switches

The commands take seconds. The investigation takes much longer, and the difference is spent moving between applications.

The loop looks like this. Finder shows low free space. Terminal runs du. A path from the output gets copied back into Finder to see what is actually in there. The contents are ambiguous, so a third window opens to ask an assistant whether it is safe to remove. Then the descent continues one level down, and the loop repeats.

Four context switches per directory, multiplied by the number of levels, is where the time goes. A file manager with a terminal and an assistant in the same window removes the copying step entirely, because the path in the shell and the folder on screen are the same object. The capabilities that make that possible are described on the features page, and the differences from Finder and other tools are set out in this comparison. Costs are listed on the pricing page.

What to change first

Stop opening with a file-size list. Run du -h -d 1 -t 500M and descend by branch instead, and check free space on the data volume rather than on the root path. Those two habits change which directory gets found, not just how fast. If the copying of paths between a file browser, a shell and an assistant is the part that drags, Atriens puts them in one window.