# Why the macOS System Data number never adds up

> System Data is not a folder and not a category — it is a subtraction. Here is exactly what macOS puts in it, why the figure moves when you are not looking, and how to get a number you can act on.

Canonical: https://bytesweep.app/blog/system-data-explained-numbers.html
Last updated: 2026-10-18

## Why the System Data number never adds up

The grey System Data segment in System Settings, General, Storage is often the biggest thing on the bar, frequently over 100 GB, and clicking it does nothing. That’s because there is nothing to open. System Data is a subtraction: total used space minus everything macOS managed to put in a named bucket.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 25 September 2026
- Last updated 18 October 2026
- 4 min read
- Part of [What System Data really is](https://bytesweep.app/mac-system-data.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

The named buckets (Applications, Documents, Photos, Mail, iCloud Drive, Messages and the rest) are each defined by a set of locations and file types. A file ends up in System Data because no rule claimed it, not because anything decided it belongs there. [What is System Data on a Mac](https://bytesweep.app/mac-system-data.html) lists what usually lands there, folder by folder, with what is safe to clear; this article is about the arithmetic, and why the figure moves while you watch it.

*System Data is whatever is left after the named categories are subtracted, so it holds unrelated things that change on their own.*

Seen that way, the odd behaviour makes sense. The figure changes while you do nothing, because caches, snapshots and logs change on their own. Deleting a big file may not shrink it, because that file was being counted under Documents. And two Macs with the same apps can differ by 80 GB in this one number, because the remainder depends on how each machine is used.

### What usually makes up the remainder

The mix depends on the machine, but the list is short and fairly stable:

| What | Where it lives | Typical size |
| --- | --- | --- |
| APFS and Time Machine local snapshots | Not in the file system you can browse | 10–80 GB |
| Xcode build products and device support | `~/Library/Developer` | 20–60 GB on a dev machine |
| Docker’s disk image | `~/Library/Containers/com.docker.docker` | 15–60 GB |
| Local AI model stores | `~/.ollama`, `~/.cache/huggingface` | 0–200 GB |
| Application caches | `~/Library/Caches` | 2–15 GB |
| System logs and diagnostics | `/var/log`, `~/Library/Logs` | 0.5–5 GB |
| Swap and the sleep image | `/System/Volumes/VM`, `/private/var/vm` | 1–20 GB |

iPhone backups and Mail used to be on this list. Current macOS counts them under iOS Files and Mail instead, so they no longer explain a large grey segment. [What is System Data on a Mac](https://bytesweep.app/mac-system-data.html) goes through every item with its path and what is safe to clear.

Snapshots are the hardest entry to see, since they aren’t files in any directory you can list. Apple says the space they use is counted as available, so how much of them shows up in the grey segment varies, but they are the usual reason the free-space figures disagree. [What APFS snapshots are and why they are invisible](https://bytesweep.app/blog/apfs-snapshots-explained.html) covers them. The read-only system volume that accounts for another chunk is in [the sealed system volume](https://bytesweep.app/blog/macos-sealed-system-volume.html).

### Measure the directories instead

Chasing the grey bar is a poor use of an afternoon. Measuring what’s under it is not. Start with the file system’s own total:

```
df -H /System/Volumes/Data
```

Then size the big directories, which gives you one figure per item instead of one grey block:

```
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 doesn’t wander into mounted volumes or network shares and count them twice. Expect `df`'s used figure and the sum of the `du` lines to disagree by several gigabytes. Why df, du and the Finder never agree explains where that gap comes from.

### Why it jumps between two glances

Three things update the bar independently. Time Machine takes local snapshots hourly and expires them after 24 hours, so the space they hold rises and falls through the day. Purgeable space is released lazily, only when something needs the room, so it can sit in the bar long after the pressure that created it has gone. And the category sizes themselves are worked out in the background and cached, so the bar can redraw without a single byte moving. Apple’s own guide says the category “varies in size depending on the current state of your Mac”, which is as close to an admission as the documentation gets.

None of that is yours to control. The directories are.

### What it is not

Two things get blamed for System Data that are counted elsewhere. Purgeable space is room macOS could give back (expired snapshots, cached iCloud files) and is shown as available, not as System Data; purgeable versus available separates the two. The macOS row is the sealed system volume, a fixed cost you cannot change, and advice to “delete system files” to shrink System Data is left over from before that volume existed.

### What is safe to reclaim

From the table, the reliably safe items are Xcode build products, Docker’s reclaimable layers and package manager caches. The reliably unsafe ones are anything in `~/Library/Application Support` you can’t identify, the most recent local snapshot if Time Machine is your only backup, and anything inside a running app’s container.

The risky middle ground is the folder that looks like a cache and isn’t: a Photos library, a Mail index, a note-taking app’s local database. What is actually safe to delete in ~/Library/Caches draws that line item by item.

### Questions

#### Why did it grow by 30 GB overnight?

Usually snapshots. Sometimes a Time Machine backup that started and didn’t finish, occasionally a log a misbehaving process wrote all night. Check snapshots first with `tmutil listlocalsnapshots /`.

#### Does reinstalling macOS fix it?

No. A standard reinstall replaces the system volume and leaves the data volume alone, and System Data is overwhelmingly on the data volume. You’d spend an afternoon to get back a few gigabytes.

#### Why is there more free space after a restart?

A restart drops swap files and a lot of cached state, and gives macOS a natural moment to release purgeable space. A few gigabytes back is normal.

### Let Bytesweep clear this for you

Skip the commands. Bytesweep finds this for you, rates every item safe, review first or keep, and clears what you choose. Most of what it removes can be put back for seven days. See what it finds on your own disk, free for 3 days, then pay once with no subscription.

[Try it free for 3 days](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

Related in Bytesweep: [Storage analyzer](https://bytesweep.app/mac-disk-space-analyzer.html)

### Keep reading

- [**APFS snapshots: the space you can’t see or easily delete** A snapshot is a frozen reference to every block on the volume at one moment. What that means for free space, why a snapshot has no single size, and how to read diskutil's snapshot list properly.](https://bytesweep.app/blog/apfs-snapshots-explained.html)
- [**Swap files and the sleep image on a Mac** macOS writes swap on demand and a full copy of RAM to disk before hibernating. On a 64 GB machine that is 64 GB of disk you did not allocate. What each is for and which can safely be changed.](https://bytesweep.app/blog/mac-swap-and-sleepimage.html)
- [**The sealed system volume, and the 12 GB you cannot touch** macOS keeps itself on a separate, cryptographically sealed, read-only volume. What that means for your free space, why it looks like duplicated data, and why every "delete system files" guide from before 2020 is now wrong.](https://bytesweep.app/blog/macos-sealed-system-volume.html)