System Data huge on your Mac: what it actually is and how to shrink it

Where you see it, and why Apple keeps it vague

On recent macOS versions the number lives in System Settings, under General, then Storage. On older versions it is Apple menu, About This Mac, Storage. The colored bar sorts your disk into Apps, Documents, Photos, and so on, and then dumps the remainder into a gray segment called System Data.

The category is vague by design. macOS only labels what it can positively identify. A photo in your Photos library is clearly a photo. But a 40 GB Docker disk image, 20 GB of Xcode build products, and 6 GB of Slack cache have no category of their own, so they all land in the gray bar. Apple's storage screen will not tell you which one you have. You have to look.

What macOS actually counts as System Data

In practice, System Data on a real Mac is dominated by a short list of things:

• App caches and support files in ~/Library (Caches, Application Support, Containers, Group Containers)
• Logs and diagnostic reports, usually small but occasionally runaway
• Time Machine local snapshots, hourly copies of changed files kept on the internal disk
• Developer tooling: Xcode's DerivedData, iOS device support files, simulator images, package caches for npm, pip, cargo and friends
• Virtual machine and container disks: Docker Desktop, UTM, Parallels
• Local AI models, Ollama and LM Studio downloads regularly reach tens of gigabytes
• Old iPhone and iPad backups made through Finder
• Anything else in a hidden folder that Storage cannot classify

See what your System Data really is

Skip guessing. Two minutes in Terminal tells you where the bulk sits. This command sizes everything in your user Library and sorts the worst offenders to the top:

Expect Caches, Application Support, Containers, and Developer to lead the list on most machines. Anything over a few gigabytes deserves a closer look before you touch it.

For the hidden dot-folders that developer tools scatter around your home folder, run the same check there:

If you would rather see it as a picture, a disk map app shows the whole disk as proportional blocks. Diskmack draws that map and labels each block with what the folder is and whether deleting it is safe, which is exactly the question this article is answering the slow way.

du -sh ~/Library/* 2>/dev/null | sort -hr | head -20

The usual suspects, ranked by how big they get

Every Mac is different, but the same folders show up in the top ten again and again. Check these first, each links to a full explanation of what it is and the safe way to clean it:

• Docker Desktop's disk image, commonly 20 to 100 GB, and it does not shrink on its own when you delete containers
• Xcode DerivedData and iOS device support, 10 to 80 GB on a development Mac
• Local AI models from Ollama, LM Studio, or the Hugging Face cache, 10 to 100 GB if you have experimented with local models
• Old iPhone backups in MobileSync, 5 to 60 GB each, and Finder keeps every device you ever synced
• ~/Library/Caches itself, usually 2 to 15 GB spread across hundreds of apps
• iCloud Drive's local mirror in Mobile Documents and app data in CloudStorage
• Application Support, where Electron apps like Slack and Discord keep multi-gigabyte caches

Time Machine local snapshots, the invisible chunk

If your numbers still do not add up, snapshots are the classic culprit. When Time Machine is on and the backup disk is not connected, macOS saves hourly snapshots of changed files to the internal disk. They also appear when a backup is interrupted. APFS counts them as purgeable, but the Storage screen rolls them into System Data, so a Mac can show 80 GB of System Data where 40 GB is snapshots waiting to be reclaimed.

List them with the command below. Each line is one snapshot with a date stamp. macOS deletes them automatically when the disk gets tight, but it is conservative about it; you can delete a specific one with tmutil deletelocalsnapshots followed by the date portion of its name. They cost you no history on your actual backup disk, snapshots are a convenience layer on top of real Time Machine backups, not a replacement for them.

tmutil listlocalsnapshots /

What not to delete

A few things inside the System Data bucket look like junk and are not. The top-level ~/Library folder itself is your entire app configuration; delete it and every app on the Mac starts from scratch or breaks. Application Support contains real user data for many apps, notes databases, browser profiles, game saves, so treat it folder by folder, never as one sweep. Containers and Group Containers hold sandboxed app data and permissions metadata; removing a container wipes that app's state.

The same goes for anything under /System and /Library at the root of the disk. macOS protects most of it, and the parts it does not protect are shared frameworks and drivers that apps depend on. The space you can actually reclaim lives almost entirely in your own home folder. Stay there and the worst case is re-downloading something; stray into system folders and the worst case is a reinstall.

A sane order of attack

Work from the biggest, safest wins down to the fiddly stuff. First, the developer and VM heavyweights if you have them: prune Docker from inside Docker Desktop, clear DerivedData, delete models you no longer run. Each of those is a one-line official command or a straightforward Finder delete, and each can return double-digit gigabytes.

Second, old iPhone backups: Finder, your device, Manage Backups, delete the stale ones. Third, app caches: clear the big individual offenders (Slack, Spotify, browsers) using each app's own settings where offered, or by emptying the app's folder inside ~/Library/Caches. Fourth, check snapshots as covered above. Then empty the Trash, deleted files still occupy disk until you do.

Resist the urge to finish the job with a blanket delete of everything gray in a disk map. The gray is exactly the part where a wrong guess costs you app data. If a folder is big and you cannot tell what it is, look it up before you delete it; every folder in our storage guide has a plain-English answer.

If System Data is still huge after all that

Give the Storage screen time. macOS recalculates categories lazily, sometimes hours after the space is really free, and purgeable space only shrinks when the system decides to reclaim it. Restarting forces some of that housekeeping.

If the number stays stubborn, measure reality instead of trusting the bar: df -h / in Terminal shows true free space, and a fresh du sweep of ~/Library shows whether anything actually big remains. When those disagree with the Storage screen, believe Terminal. And if the remaining bulk is hundreds of small folders rather than one obvious hog, that is the point where a labeled disk map saves an afternoon: Diskmack scans the disk, explains each folder, and cleans the safe ones with the tool's own official commands or a move to the Trash, nothing destructive.

df -h /

Common questions

Related folders

• Is It Safe to Delete Xcode's DerivedData Folder?
• Docker Desktop Taking Up Space on Mac: What's Safe to Delete
• Can You Delete the Library Caches Folder on a Mac?
• Is It Safe to Delete Old iPhone Backups on Your Mac?
• Ollama models taking up space on your Mac? How to delete them safely
• Is the Hugging Face cache safe to delete? What's inside ~/.cache/huggingface
• Application Support Folder Is Huge: What's Safe to Delete?
• Is It Safe to Delete ~/Library/CloudStorage on a Mac?
• Mobile Documents Folder Huge on Your Mac? Don't Delete It Directly