Why the System Data number never adds up

On this page

1. System Data is a remainder, not a category
2. What is actually in there
3. Getting a number you can act on
4. Why the bar moves while you watch it
5. What is safe to reclaim, and what is not

System Data is a remainder, not a category

macOS classifies files it recognises into the named buckets you see on that bar: Applications, Documents, Photos, Music, Mail, iCloud Drive, Messages, and so on. Each bucket is defined by a specific set of locations and file types.

System Data is everything left over. It is total used space minus the sum of the buckets. Nothing decides that a file belongs in System Data; a file lands there because no other rule claimed it.

That single fact explains most of the confusing behaviour:

• It changes when you have not touched anything, because the things inside it — caches, snapshots, logs — change on their own.
• It cannot be opened, because there is no directory to open.
• Deleting a large file may not reduce it, if that file was being counted in Documents.
• Two Macs with the same applications installed can differ by 80 GB in this one figure.

What is actually in there

The contents vary by how the machine is used, but on a typical Mac the list is short and the order is fairly stable.

Snapshots are usually the largest entry and the least visible one, because they are not files in any directory you can list. What APFS snapshots are and why they are invisible covers that, and the sealed read-only volume that accounts for another chunk is dealt with in the sealed system volume.

Getting a number you can act on

Start with the honest total. df reports what the file system knows, in the units the file system uses:

df -H /System/Volumes/Data

Then measure the large directories yourself, which gives you a figure per item rather than one grey bar:

sudo du -xh -d 1 /System/Volumes/Data 2>/dev/null | sort -h | tail -20
du -xh -d 1 ~/Library 2>/dev/null | sort -h | tail -20

-x keeps du on one file system so it does not wander into mounted volumes or network shares and count them twice. Expect the two numbers — df's used figure and the sum of du — to disagree by several gigabytes; why df, du and the Finder never agree explains where the gap comes from.

Why the bar moves while you watch it

Three separate mechanisms update independently, which is why the figure can jump by 20 GB between two glances at the same screen.

• Snapshots are created hourly and expire after 24 hours, so the amount they hold rises and falls all day.
• Purgeable space is recalculated lazily. macOS frees it only when something genuinely needs the room, so it can sit in the bar long after the pressure that created it is gone.
• The bucket sizes themselves are computed in the background by diskarbitrationd and Spotlight metadata, and the answer is cached. A reindex changes the picture without a single byte moving.

None of that is under your control, which is why chasing the number is a poor use of an afternoon. Chasing the directories underneath it is not.

What is safe to reclaim, and what is not

Of the list above, the reliably safe items are Xcode build products, Docker’s reclaimable layers, package manager caches, and old device backups you have since replaced. The reliably unsafe ones are anything in ~/Library/Application Support you cannot identify, the most recent local snapshot if Time Machine is your only backup, and anything inside a running application’s container.

The genuinely dangerous middle ground is the folder that looks like a cache and is not: a Photos library, a Mail index, a local database used by a note-taking application. What is actually safe to delete in ~/Library/Caches draws that line item by item.