Finding the files eating your disk

The startup disk warning arrives, a few gigabytes get cleared, and the warning comes back the next morning. Storage settings say one thing, the Finder Get Info window says another, and adding up the visible folders does not come close to the total. Anyone searching for find large files mac os in that state has usually already emptied the Trash and deleted a few videos. The remaining question is different: what is holding the space that nothing in the interface is showing.

There are two separate problems tangled together. One is locating individual large files, which is straightforward once the right criteria are used. The other is accounting for space that belongs to no visible file at all, which is the reason the arithmetic never works. Solving them in that order saves a lot of pointless deleting.

Why the numbers never add up

Open the Apple menu, then System Settings, then General, then Storage. The bar chart there is the closest thing macOS gives to an official answer, and it will disagree with a manual count for three reasons.

The first is purgeable space. APFS reports storage that the system believes it can reclaim on demand as available, even though it is currently occupied. Files stored in iCloud with local copies, caches, and old snapshots all count. Finder shows the optimistic number, and a disk that says it has 40 GB free can refuse a 20 GB write when the reclaim does not happen fast enough.

The second is local Time Machine snapshots. macOS keeps hourly snapshots on the internal disk, not only on the backup drive, so that a backup can be made when the external disk is not attached. These hold onto deleted data by design. tmutil listlocalsnapshots / prints what exists. This is the single most common reason that deleting 30 GB of video frees nothing at all: the data is still referenced by a snapshot until that snapshot is thinned.

Deleting a large file does not free space if a snapshot still points at it. The space returns when the snapshot expires, which is usually within 24 hours, or immediately if the snapshot is removed deliberately.

The third is that some of the largest items on a working Mac are packages and libraries rather than files. A Photos library, a Mail folder, a virtual machine image, and an application bundle all appear as one item in Finder. Their contents are invisible without either opening the package or asking a tool that counts recursively.

The folders that hold the weight

Before running any scan, it is worth knowing where the mass usually sits, because five locations account for the majority of it on most machines.

Developer tooling is first, and it is the one people underestimate most. Build caches under ~/Library/Developer, simulator runtimes, device support files for every iOS version ever connected, and node_modules directories scattered through project folders together reach tens of gigabytes without anything appearing in Documents.

Container and virtual machine images are second. Docker keeps a single disk image that grows and does not shrink on its own. docker system df reports what is inside it, and docker system prune reclaims part of it, but the image file itself often stays at its high water mark until it is reset.

Device backups are third. iPhone and iPad backups made through Finder are stored under ~/Library/Application Support/MobileSync/Backup, one folder per device, and old ones are not removed automatically. Each is roughly the size of the device it came from.

Mail is fourth. Attachments are downloaded and kept locally by default, and a mailbox that has been carried across three machines can hold years of them.

Downloads is fifth and simplest. It is the only one on this list that most people already check, which is why it is rarely the answer by the time the search starts.

Two smaller cases are worth adding because they hide in plain sight. The Trash is per volume, so an external drive that was used months ago can be holding a full copy of everything ever deleted from it, and emptying the Trash from a Finder window on the internal disk does not touch it. A Photos library is the other. Importing the same card twice produces two full resolution copies of every image, and the duplicates live inside the library package where no folder listing shows them. Both are reclaimed from inside the application that owns them rather than by deleting files underneath.

Finder can do this, once two things are changed

Finder is capable of a size search and does not advertise it. Two changes make it usable.

Add the size criterion

Open a Finder window, press Cmd+F, and click the plus button at the right of the criteria row. The default menu does not include size. Choose Other, then find File Size in the list, and tick it so it stays available. Setting File Size is greater than 500 MB, with the scope set to This Mac, produces a plain list of every large file the index knows about. Adding a second row for Last modified date before a given month separates the large files that are still in use from the ones that are not.

Save that query with File, then New Smart Folder. A saved search for large old files is worth keeping in the sidebar permanently, because this problem recurs.

Make folder sizes visible

In list view, choose View, then Show View Options, and tick Calculate all sizes. Finder will then compute folder sizes rather than showing two dashes. It is slow on large folders and it applies per window unless it is set as the default, but it turns a folder listing into something that can be sorted by size, which is what the search needed in the first place.

The limit of both techniques is that Finder searches the metadata index, so anything excluded from that index is invisible. Folders on the Search Privacy list, volumes with indexing disabled, and hidden directories will not appear regardless of how large they are. That exclusion is the reason a Finder size search frequently accounts for only half the missing space.

The command line gives the answer by folder

The question that actually matters is rarely "which file is largest" but "which directory is heaviest", and that is what du reports.

Run du -h -d 1 ~ | sort -h to get the top level of a home folder sorted from smallest to largest. Then run it again one level down inside whatever came out on top. Three or four rounds of that lands on the real culprit, and it works on folders that no index covers.

Two caveats matter. The first is permissions: several directories under a home folder are protected, and du will print permission errors for them unless Terminal has been granted Full Disk Access in the Privacy and Security section of System Settings. The second is that du reports allocated blocks, so APFS clones and sparse disk images can be counted in ways that do not match intuition. A virtual machine image that shows as 60 GB may hold far less real data.

For a file level answer, find ~ -type f -size +1G lists everything above a gigabyte, and the threshold can be lowered until the list is long enough to be useful. Piping it through xargs -I{} du -h {} adds sizes, and sort -h puts the worst at the bottom.

ncdu, installed through Homebrew, wraps the same idea in a navigable interface. It scans once, then allows moving up and down the tree with arrow keys, with sizes recalculated as the view changes. For a repeated investigation it is faster than running du by hand, and it deletes from inside the interface, which is either convenient or dangerous depending on the hour.

Which tool for which question

Tool	Answers	Sees unindexed and hidden items	Cost
Storage settings	What the system thinks each category holds	Yes, at category level only	Included with macOS
Finder size search	Which individual files are over a threshold	No	Included with macOS
du and find	Which directory or file holds the weight	Yes, with Full Disk Access	Included with macOS
ncdu	The same, navigable and interactive	Yes	Free, installed separately
GrandPerspective, OmniDiskSweeper	The same as a visual map or sorted tree	Yes	Free downloads
DaisyDisk	The same, with a polished map and drag to delete	Yes	Paid application

The visual scanners are worth the download for one specific reason. A treemap shows proportion at a glance, and a folder that is 40 percent of a disk is obvious in a map in a way it is not in a sorted list of numbers. For a machine that is being cleaned once, that is the fastest route. For a machine that will need cleaning again next quarter, the du habit is the one that lasts, because it works over SSH, inside a script, and on volumes that no scanner has permission to read.

Deleting the right things

Three categories are safe to remove without further thought. Build caches regenerate. Downloaded installers and disk images have served their purpose. Old device backups for hardware that no longer exists are dead weight.

Three categories deserve care. Anything inside a ~/Library folder that belongs to a running application can break that application's state, and the space saved is often small. Photos and Mail libraries should be managed from inside their applications rather than by deleting files underneath them. Snapshots and cache directories that macOS manages will be reclaimed automatically, and forcing the issue occasionally costs more than it recovers.

One habit is worth more than any of it. After a large deletion, check the free space number again after a few minutes rather than immediately, because snapshot thinning and purgeable space reclamation both happen on a delay. The disk that appeared not to change often has.

The part that is slower than it looks

The investigation itself is a loop: look at a folder listing, run a command against the folder that stands out, read the output, move down a level, repeat. Done between a Finder window and a separate terminal, every step costs a path copy with Cmd+Option+C, a window switch, and a paste.

That loop is the argument for keeping the folder view and a command prompt in one window with a shared working directory, which removes the copy and the switch from every iteration rather than making each one slightly faster. The Features page describes how that is laid out, and the Compared with other file managers page places it next to the dual pane and terminal based tools that approach the same problem from the other side.

What to change first

Run tmutil listlocalsnapshots / and check the local snapshots before deleting anything, because that single command explains most of the space that appears to be missing. Then work down the tree with du -h -d 1 rather than hunting for individual large files. If the switching between the folder listing and the command is what makes this tedious, Atriens puts both in the same window.