‘System Data’ Isn’t a Thing You Can Delete: What macOS Storage Is Really Counting

Your Storage bar says “System Data: 120 GB” and there is no button to open it, nothing to delete, no explanation. Here is what that slab actually is — mostly snapshots, purgeable space, and an arithmetic remainder — and why deleting things can make it grow.

By CoreGuard · Jul 6, 2026 · 13 min read

You open Storage settings to find out where your disk went, and there it is: a fat grey slab reading System Data — 120 GB. No icon, no chevron, no “Show in Finder” — just a number the size of a game library, implying you have a hundred-odd gigabytes of something rotting on your drive. Search “System Data Mac” and the internet tells you to delete your caches and install an app to make it disappear. Most of that is useless, and some of it makes the number bigger.

What is “System Data” on a Mac?

Here is the one-sentence version: System Data is not a folder, a file, or a heap of junk. It is the leftover. macOS Storage adds up every category it knows how to label — Applications, Photos, Music, Mail, Messages, Documents — and whatever space it can’t sort into one of those buckets gets swept into System Data. As Howard Oakley of The Eclectic Light Company puts it, “Storage appears to total all other categories up and account for the remainder of storage used in the category System Data.” It is not something macOS measured. It is the arithmetic remainder of everything it didn’t.

What lands in that remainder is genuinely mixed: app and system caches, log files, APFS snapshots, virtual-memory swap, fonts, and a long tail of things macOS simply has no category name for. Some of it is transient. Some of it is working data you should leave alone. And crucially, the panel gives you no way to tell which is which — Oakley’s verdict is blunt: “System Data is the one category that desperately needs further information, but doesn’t have a button.”

It can also be legitimately enormous. In Oakley’s own example, “System Data is by far the largest of all the categories, and accounts for half the space used on this SSD.” Half. That is not a bug and not junk — it is what a healthy, working macOS install looks like when you refuse to break it down into its parts.

Why it looks so enormous

A few large, completely normal things pile into that bucket, and they explain most of a scary number.

The biggest are snapshots. “Backup utilities including Time Machine normally make a snapshot with each backup, and retain them for 24 hours, following which they’re automatically deleted,” Oakley writes. A snapshot freezes files as they were, which is exactly why it takes space — and why that space comes back on its own about a day later. Alongside the snapshots sit purgeable space (storage macOS will reclaim under pressure but hasn’t yet), plus the running total of caches, logs, swap and fonts. None of it is junk; most of it is macOS doing its job.

And here is the myth worth killing, because it comes up every time: the operating system itself is not secretly hoarding gigabytes inside System Data. The sealed system volume is, per Oakley, “just over 12 GB,” and your Mac boots from a read-only snapshot of it — but because that boot copy is a snapshot, it shares the very same blocks and doesn’t double the space. Better still, Storage settings counts the system volume separately, not under System Data. So “macOS is secretly hoarding itself inside System Data” is simply not what’s happening — the real drivers are the snapshots, purgeable space and caches above.

• Local Time Machine snapshots — kept ~24 hours, then auto-deleted; they inflate “used” in the meantime.
• Purgeable space — counts as used in some views, free in others; macOS clears it when it needs to.
• Caches, logs, swap, fonts — working files that get rebuilt if you remove them.
• The unlabelled remainder — everything macOS couldn’t sort into a named category.

The dashboard is the part that’s actually broken

Here is the honest reframe: the alarming thing on your screen is not your drive. It is the read-out. Apple built a dashboard that carefully itemises the small, easy categories and then leaves the largest one behind a number with no way to open it — and it isn’t even a reliable number.

On the Apple Support Communities, a user on a MacBook Air running macOS Tahoe (26.1) reported the Storage bar showing about 120 GB of System Data while a terminal check suggested only ~11 GB was actually in use — their measurement, on their machine, but a gap that big is its own kind of evidence. In a separate thread, when a poster asked why the figure kept swinging, a long-time community contributor answered that changes of roughly 30 GB up to 60-plus GB are “within the normal range” and that the Storage display is, in their words, not terribly reliable — sometimes just sitting on “Calculating…” indefinitely. When “30 to 60 GB of drift” is normal and the panel routinely gives up mid-count, you are not looking at an instrument. You are looking at an estimate wearing an instrument’s clothes.

The scary part isn’t the 120 gigabytes. It’s that Apple’s own dashboard can’t tell you what they are — and on some Macs it’s off by a hundred of them.

Why deleting stuff can make it grow

This is the part that turns a mild annoyance into an actual trap. In that Apple thread, a commenter reported the exact paradox: “the more I found and emptied cache the fatter the system data got — which leaves me with less storage.” They tried to shrink System Data by deleting things, and System Data grew.

It is not a glitch; it is APFS behaving as designed. When you delete files on an APFS volume, the space isn’t necessarily freed on the spot — if a local snapshot is holding that data, it stays put until the snapshot clears, which for Time Machine’s local snapshots is about a day (sometimes longer). So you empty a cache, the app quietly writes it back, and the old copy is now sitting in a snapshot counting against you too. You paid twice and freed nothing, at least for a day. A community contributor in the same discussion warned that deleting caches “will actually lead to performance issues” — caches exist because rebuilding them costs time and, yes, more disk writes.

The takeaway is almost zen: the way to make System Data smaller is usually to leave it alone and let macOS reclaim the snapshots and purgeable space on its own schedule. Fighting the number by hand mostly feeds it.

How to see where your Mac’s storage really went

If you actually want to know where your space went — rather than guess from a slab with no button — here is the read-only way to do it. Nothing below deletes anything; it only measures.

1. Open Disk Utility first: In Disk Utility choose View → Show All Devices and select your APFS container. It shows accurate Used, Free and Purgeable figures — the numbers Storage settings rounds off — and it is read-only.
2. List your local snapshots: Run tmutil listlocalsnapshots / in Terminal. These are the Time Machine snapshots macOS keeps for about 24 hours; they count as used space and inflate System Data until they clear on their own.
3. Check per-volume usage: Run diskutil apfs list to see each volume’s size, including the sealed system volume at about 12 GB. Its boot snapshot shares those blocks rather than doubling them, and Storage counts it separately from System Data — none of it is yours to delete.
4. Measure the caches that are actually large: Run du -sh ~/Library/Caches/* and sudo du -sh /Library/Caches/* to see which caches are genuinely big before you touch anything. Most will be rebuilt if removed, so measure, do not reflexively empty them.
5. Let purgeable space clear itself: If you truly need room, macOS reclaims purgeable space automatically under pressure, and a reboot clears many local snapshots. Deleting caches by hand often just moves the bytes into snapshots for a day and the number lurches up.

Do that and the mystery collapses into a list of real owners: so many gigabytes of snapshots, so much purgeable, this cache, that old backup. Which is the whole point — you can’t make a good decision about a number you’re not allowed to see.

So what should you actually do about a huge System Data?

Most of the time: nothing. A big System Data on a Mac with plenty of free space is not a problem to solve — it is snapshots and purgeable space that will clear themselves. If you are genuinely short on room, the honest moves are narrow and boring:

• Remove real, identifiable things you no longer need — old iOS device backups, giant downloads, a disk image you forgot about — found by measuring, not guessing.
• Reboot to clear local snapshots, and give macOS a few minutes; purgeable space is reclaimed under pressure.
• Turn to Disk Utility for the accurate free/purgeable figures instead of the Storage bar.

And the thing not to do: don’t hand the problem to an app that promises to “erase System Data” or “free up gigabytes” with one click. There is no “System Data” object to erase — remember, it’s a remainder — so anything claiming to delete it is really deleting caches and files it has decided you don’t need, often the exact caches macOS will rebuild an hour later. The US Federal Trade Commission has spent years bringing cases against “optimizer” and “cleaner” software that invents problems to sell a fix. A number you don’t understand is precisely the kind of problem they love to invent.

What I’m building CoreGuard to show

This is the reason I started building CoreGuard, so I’ll keep it concrete and honest — after a whole article about a dashboard that overpromises, hand-waving would be hypocritical.

CoreGuard gives you a read-only disk inventory: instead of one opaque “System Data” slab, it names the real owners it can see — your biggest files and folders, apps by size, and the actual cache and log sizes — and it tells you in plain English what’s eating your Mac right now. It is read-only in the strict sense: it shows you what is there and it never deletes, moves, or touches a single file. It observes and explains; it does not clean or optimise anything, because those are exactly the promises that get people into trouble.

And here is the honest limit, because you’ve earned it by reading this far: the snapshot-and-purgeable layer — the biggest single reason System Data looks huge — is best read with Disk Utility and tmutil, and CoreGuard will point you straight there rather than pretend it has reinvented them. What CoreGuard adds is the part macOS refuses to give you at all: a plain, itemised, read-only picture of where your space actually went — named owners instead of a blank slab. Seeing that something is wrong is always free; the detailed inventory and the exportable report are the Pro power tools, never the knowledge itself.

CoreGuard is local-only — zero network connections, no account, no telemetry; verify it yourself with lsof -i -nP | grep CoreGuard and watch nothing happen — and it’s Developer-ID signed and notarised by Apple. It can’t shrink your System Data and wouldn’t claim to. It just refuses to leave you staring at a number with no button.

CoreGuard isn’t out yet — the download and checkout go live shortly. So the honest ask: get notified and grab it free at launch, or see what Pro adds. Pro is a one-time $29 (Family $49), perpetual, not a subscription, with a 30-day money-back guarantee. Either way — next time Storage settings scares you, open Disk Utility instead, and measure.

Frequently asked questions