Mac disk space analyzers, and how to read one properly

A disk space analyzer draws your disk as an area map: every file and folder gets a share of the picture proportional to its size, biggest first. Ten seconds of looking replaces an hour of clicking through folders wondering where 200 GB went.

They are genuinely the right tool for the question where is my space. They are the wrong tool for what can I delete, and the distance between those two questions is where the trouble starts.

What the map is measuring

A treemap sums the actual bytes each directory occupies and renders that as area. That sounds obvious until you meet the four cases where the sum is not what you expect.

Packages look like files. An application, a Photos library and a Keynote document are all directories that Finder presents as single items. A good analyzer shows the package as one block, which is right for reading but means the 180 GB block labelled Photos Library.photoslibrary is not something you can open up and prune.

Hard links are counted once, or twice, depending on the tool. Time Machine backups and some package managers create multiple directory entries pointing at the same data. Tools disagree about which entry to bill for it, which is why two analyzers can give you two different totals for the same disk and both be defensible.

Sparse files lie. A virtual machine disk image may report 200 GB while occupying 40 GB, because the empty parts were never written. ls shows the claimed size; du shows the real one.

Snapshots are invisible. Local Time Machine snapshots hold real disk space and belong to no directory you can browse. Most analyzers cannot show them at all, which is the single most common reason a map’s total falls tens of gigabytes short of the disk’s used figure. What snapshots are and how to thin them.

Why your analyzer is under-reporting

If the map’s total is far below what System Settings says is used, work through these in order.

Full Disk Access. Without it, macOS hides other applications’ containers, Mail, Messages, Safari data and the Trash from any app that asks. The analyzer does not get an error — it gets an empty directory, and it quietly reports zero. Grant it in System Settings → Privacy & Security → Full Disk Access, then scan again and compare.

Snapshots and purgeable space. Covered above. Check with tmutil listlocalsnapshots /, and compare df -h /System/Volumes/Data against what Finder claims is free. The purgeable space explanation.

Other volumes. Modern macOS splits the disk into a read-only system volume and a writable data volume. Analyzing / and analyzing /System/Volumes/Data give different answers, and the second is the one you want.

Getting the same picture from du

macOS ships with du, which is what every graphical analyzer is ultimately doing.

sudo du -x -d 1 -h /System/Volumes/Data 2>/dev/null | sort -h

Reading that: -x stays on one filesystem so it does not wander into mounted volumes, -d 1 stops at one level deep, -h prints human-readable sizes, and sort -h puts the largest at the bottom where you will see it.

The output is your top-level breakdown. Pick the biggest line and repeat one level down:

sudo du -x -d 1 -h ~/Library 2>/dev/null | sort -h

Three or four rounds of that reaches the same place a treemap reaches, and it costs nothing. The sudo matters — without it you get permission errors on exactly the directories most likely to be holding the space.

For a flat list of the worst offenders regardless of depth:

sudo du -x -h /System/Volumes/Data 2>/dev/null | sort -h | tail -40

Slower, because it walks everything, and worth it once.

Reading the result without breaking something

Here is where a map stops helping. The largest directories on a perfectly healthy Mac are, in rough order: your Photos library, ~/Library, Applications, your Documents, and on a developer’s machine ~/Library/Developer. None of those are deletable. Size is not evidence of waste.

What the map is good for is spotting the thing that does not belong: a 60 GB directory you have no memory of, a folder of video exports from a project that shipped last year, an iOS DeviceSupport folder holding every iOS version since 2019. You are looking for surprise, not for size.

Before deleting anything a map surfaced, ask what writes to it. If you cannot answer, do not delete it — move it to an external drive for a week instead, and see what complains.

Which tool

du — free, exact, already installed, no picture. Best if you want the numbers and are comfortable in a terminal.

DaisyDisk — the best pure visualiser on the platform, and deliberately limited: it shows you the map and lets you drag things to a delete pile. It does not categorise, uninstall, or decide anything for you, which is exactly why people who like it like it. If all you want is the picture, it is the picture done properly. Longer comparison.

CleanSpace — includes a disk map, Space Lens, alongside category-based scanning. Different trade: the map answers where, and the categories propose what, with real sizes and nothing preselected. Scanning is free, so the map costs nothing to look at.

If you only need to answer this question once, the du commands above are genuinely enough, and they are the same measurements everything else is built on.