The hidden storage on your Mac: where your disk space really goes

Your Mac never gives you a receipt for its own storage. You open Settings, see a bar chart with a fat grey slice labeled System Data, hover over it, and macOS tells you… nothing you can act on. Meanwhile the disk fills up.

There's no official figure for how much a laptop hides; nobody measures it. But every piece is documented, and when you add them up, it's easy to see how a working Mac quietly gives up 100, 150, even 200 GB to files you never chose to keep. People post to Apple's own forums with 218 GB sitting in System Data alone. This is a map of where it all goes.

First: the number you see is a guess

Open System Settings → General → Storage. That grey System Data block is not a folder. It's a leftover category. Everything macOS couldn't sort cleanly into Apps, Photos, Music, or Documents gets swept into it. The macOS-internals community that reverse-engineers this stuff describes it bluntly as "little more than a guesstimate."

It's not even accurate. One documented case: a 100+ GB Music library showed as under 50 GB, and the missing ~50 GB was silently dumped into System Data, miscategorized rather than hidden junk. And Apple tells you outright that "you can't directly manage the contents of this category."

So the one number most people go looking at is the one number macOS refuses to explain. That's the whole problem in miniature.

The tools don't even agree with each other

Ask three different tools how much space you have free and you'll get three different answers:

df -h /                    # what the filesystem says — trustworthy
du -sh ~/SomeFolder        # sums files it can walk — under-reports

• Finder is frequently, wildly wrong. A macOS researcher caught Finder reporting 83.71 GB purgeable when the real purgeable amount was 0 GB.
• du only sums files it can see and walk. It can't see snapshot-retained blocks or purgeable data, so it under-reports.
• df reports what the filesystem itself says is used and free. For real free space, trust this, or open Disk Utility and select the APFS container (not the volume).

If you've ever felt like your Mac's storage math doesn't add up, you're right. It literally doesn't.

Cache: speed you pay for in disk space

A cache is a local copy of something an app expects to need again (website assets, thumbnails, search indexes, compiled build output), kept around so it doesn't have to fetch or recompute it. It's a deliberate trade of disk space for speed.

The catch is that almost nothing prunes its own cache. It just grows. Individual apps routinely sit on 1–3 GB each. You'll find caches in three places:

# your app caches (per-user) — the big, safe-to-clear ones
du -sh ~/Library/Caches/* 2>/dev/null | sort -rh | head -20

• ~/Library/Caches: per-user app caches. Generally safe to clear: macOS and the app rebuild what they need next launch. The only cost is a slower first load.
• /Library/Caches: system-wide.
• /System/Library/Caches: OS-managed. Leave these alone. (Booting into Safe Mode clears certain system caches, and macOS rebuilds them automatically, which is the intended way.)

One caveat: some apps abuse the Caches folder to store data that isn't actually disposable. Blanket-nuking everything can lose real state. Clear caches for apps you're not actively using; be careful with the ones you depend on.

Purgeable space and the snapshots you can't see

"Purgeable" is Apple's word for space macOS will free up on demand. You can't delete it yourself. A big contributor is APFS local snapshots.

When Time Machine (or a macOS update) takes a snapshot, APFS doesn't copy your files. It just freezes the current filesystem state. But as you change files afterward, the original blocks have to be kept as long as the snapshot references them. That retention quietly eats space you can't see in Finder.

tmutil listlocalsnapshots /     # list local APFS snapshots

macOS is supposed to manage these: snapshots older than 24 hours auto-delete, and more get purged when the disk runs low. But "supposed to" and "does" aren't always the same, and, tellingly, the experts don't even agree on what counts as purgeable. Cleaner vendors say it's mostly snapshots; the most rigorous independent analysis says macOS counts snapshots as used space and that purgeable is really caches, Spotlight indexes, and version databases. When the people who study this for a living can't reconcile the number, you shouldn't feel bad that you can't either.

The hidden folder where all of this lives: ~/Library

Most of the invisible weight sits in a folder Finder hides from you by default. It's hidden on purpose, so you don't accidentally delete something an app depends on, not because it's secret:

open ~/Library                  # or: hold ⌥ Option and use Finder's "Go" menu
chflags nohidden ~/Library      # unhide it permanently

Inside, the space goes to:

• Application Support is the bulk of an app's per-user data: databases, plug-ins, downloaded models, project state. Often the single biggest thing an app leaves behind.
• Containers / Group Containers: sandboxed-app data (Mac App Store apps, Docker, and friends).
• Caches: the disposable stuff from above.
• Logs, Saved Application State, Preferences: small individually, endless in aggregate.

None of this lives inside the app. The .app in your Applications folder is just the program. Everything above is stored separately, which is exactly why it survives when you delete the app.

Apps don't really uninstall on a Mac

On macOS, "uninstalling" usually means dragging an app to the Trash. That removes the .app bundle and nothing else. Left behind, scattered across ~/Library:

• Application Support/<app>: often the largest leftover
• Preferences/<app>.plist: your settings
• Caches/<app> and Containers/<app>
• Logs, Saved Application State
• LaunchAgents / LaunchDaemons: background helpers that can keep running after the app is gone
• Login items

As one guide puts it: sometimes more data is left behind than deleting the app freed up. Do this across years of apps you tried once and abandoned, and the residue adds up to real gigabytes, for software you don't even have anymore. (Free tools like AppCleaner and PearCleaner exist entirely because macOS doesn't do this for you.)

Developer build-up: the fast lane to a full disk

If you write code, your machine hides storage on a completely different scale. This is where 20 GB turns into 100.

• node_modules graveyards. A single project pulls hundreds of MB of dependencies; you have dozens of cloned projects you'll never touch again. Find them all:

  find ~ -name "node_modules" -type d -prune -print0 2>/dev/null \
    | xargs -0 du -sh 2>/dev/null | sort -rh | head -20
  

• Xcode. The single biggest offender for Apple devs. DerivedData, simulators, and per-version device support commonly total 20–50 GB. DerivedData alone is often 2–15 GB, and every iOS version you've ever debugged leaves a 5–8 GB DeviceSupport folder that never gets pruned.

  du -sh ~/Library/Developer/Xcode/DerivedData
  

• Docker.raw: the classic "grows but never shrinks." Docker runs a Linux VM whose entire disk is one file. It expands as you add images, but deleting them inside Docker doesn't shrink the file. The host-side .raw keeps its high-water mark. One documented case: 67 GB on disk for 15–20 GB of actual content.

  du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
  docker system prune          # reclaim space *inside* the VM
  

• Package-manager caches that never clean themselves. Homebrew's download cache commonly reaches 3–6 GB (brew cleanup clears it); npm, pip, Cargo, and Gradle each keep their own growing cache; every Python venv duplicates its dependencies again.

So where did the 200 GB go?

There's no honest "average" to quote, so here's the alternative. The pieces, each with its documented range, added up for a realistic developer's Mac.

That's not a statistic. It's an example, and every row is sourced from documented behavior. But you can see how a working laptop crosses 100, then 150, then 200 GB of storage you never chose to keep. The 218 GB System Data reports on Apple's forums aren't outliers. They're what happens when nothing ever cleans up after itself and the tool that's supposed to show you won't.

Seeing it, without guessing

You can dig all of this out by hand with the commands above. It's tedious, and it's easy to delete the wrong thing when Finder, df, and du are all telling you different numbers.

That's the job Plumby is built for. It draws the map Apple won't. It breaks "System Data" into named pieces with exact paths, reconciles the gap between what Finder, df, and du each claim, and finds the developer build-up across your whole machine: every node_modules, DerivedData, the Docker.raw, and stale caches. Then it clears only what's safe. Freed space is measured as each item goes, so nothing is estimated. Anything it clears can go to the Trash rather than be deleted, so you can put it back. And it never touches your documents, photos, or projects, only the regenerable junk.

Your Mac won't show you where the space went. Something should.