Sweepfor Mac

Mac maintenance

What Is 'System Data' on Mac, Really? (A Deep Dive)

System Data on Mac is a catch-all bucket that can balloon to 100GB+. Here's what's actually in it, why it grows, and how to shrink it without breaking macOS.

11 min read

You open System Settings → General → Storage, hover over the colored bar, and there it is: System Data, 142 GB. That’s bigger than your Photos library. Bigger than every app you’ve installed combined. And Apple’s tooltip helpfully tells you it’s “files used by your system” — which explains nothing.

System Data is the bucket macOS dumps everything it can’t categorize neatly. It’s not a bug, and it’s not a virus. But it’s also not as untouchable as the vague label suggests. Once you know what’s actually in there, you can recover serious space without resorting to terminal voodoo or third-party “cleaners” that delete things you needed.

What ‘System Data’ Actually Contains

The Storage pane in System Settings categorizes files by reading their extended attributes and matching them against known kinds (photos, mail, documents, apps). Anything that doesn’t match a category — or that the categorizer can’t quickly classify — falls into System Data. That includes a lot:

  • Caches at /Library/Caches, ~/Library/Caches, and /System/Library/Caches
  • Logs at /var/log, ~/Library/Logs, and /Library/Logs
  • Application support files at ~/Library/Application Support (Slack alone can hit 5+ GB here)
  • Time Machine local snapshots stored on the boot volume
  • Mail attachments that aren’t classified as Mail (downloaded inline images, mostly)
  • Xcode derived data at ~/Library/Developer/Xcode/DerivedData
  • iOS device backups at ~/Library/Application Support/MobileSync/Backup
  • Old macOS installer remnants if a previous upgrade didn’t clean up
  • Virtual machine disk images that VM apps register outside the Documents folder
  • Browser service workers and IndexedDB stores

That last one catches people. If you use ChatGPT, Notion, Linear, or any heavy web app pinned in your browser, the IndexedDB store can hit several gigabytes per site, and Storage doesn’t count it as “Browser” data — it counts it as System Data.

Why It Grows So Aggressively

macOS has a philosophy of being aggressive about caching anything that takes time to compute or download. The assumption is that disk space is cheap and recomputing is expensive, so a 50 GB cache that saves three seconds per launch is a good trade. That’s a fine philosophy if you have a 2 TB SSD. It’s miserable on a 256 GB MacBook Air.

A few specific growth drivers worth knowing:

  1. Time Machine local snapshots — Even if you don’t have an external drive plugged in, macOS quietly takes hourly local snapshots of changed files, holding them on your boot SSD until they can be flushed to a backup. They cap at about 80% of free space, but they’re real bytes.
  2. Photos library “Optimize Mac Storage” — When this is on, the system caches recently-viewed full-resolution photos locally. That cache lives in System Data, not Photos.
  3. Music and TV downloads — Apple Music tracks downloaded for offline listening get categorized differently depending on how they were obtained.
  4. App-specific bloat — Slack’s localStorage, Discord’s cached emoji, Zoom’s update installers, Adobe’s ~/Library/Caches/Adobe — each one a few GB on a heavily-used machine.

Power users use SweepSweep handles all the cleanup that articles like this describe. Get Sweep free →

Checking What’s Actually In There

Before deleting anything, get visibility. The Storage pane lumps things together, but a few command-line tools tell the truth.

For a directory-by-directory breakdown of your home folder:

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

That sorts the largest folders inside ~/Library and usually reveals the suspects: Application Support, Caches, Containers, and Group Containers.

For Time Machine local snapshots, list them:

tmutil listlocalsnapshots /

You’ll see entries like com.apple.TimeMachine.2026-04-19-143022.local. Each one represents a point-in-time copy of your disk’s changed blocks.

To see if any APFS snapshots are reserving large amounts:

diskutil apfs listSnapshots /
Tip: Sonoma and later show local snapshots inline in System Settings → General → Storage → Time Machine, but the count is sometimes lagged by a few hours.

Safe Things to Delete (and Things to Leave Alone)

Some System Data is genuinely temporary and will be regenerated. Other parts hold real state — preferences, license tokens, or documents an app expects to find. Knowing the difference matters.

Generally safe to clear:

  • ~/Library/Caches/* — These will rebuild on next launch. Apps may briefly feel sluggish.
  • ~/Library/Logs/* — Pure history. Useful for debugging, useless otherwise.
  • ~/Library/Developer/Xcode/DerivedData — Xcode rebuilds these. Frees 20–80 GB on dev machines.
  • iOS device backups in ~/Library/Application Support/MobileSync/Backup (verify what they’re for first)
  • Old .ipsw files in ~/Library/iTunes/iPhone Software Updates
  • ~/Library/Containers/com.apple.mail/Data/Library/Mail Downloads — old attachments

Risky — know what you’re doing:

  • ~/Library/Application Support/<AppName> — May contain documents, license files, or accounts.
  • ~/Library/Containers/<bundle.id> — Sandboxed app data. Deleting this often resets the app entirely.
  • ~/Library/Group Containers — Shared data between related apps (e.g., all Microsoft Office apps).

Don’t touch:

  • Anything in /System/Library — protected by System Integrity Protection anyway.
  • /Library/LaunchDaemons and /Library/LaunchAgents without understanding what each plist starts.
  • /private/var/db — system databases.

Forcing macOS to Recategorize

Sometimes Storage just gets stuck. You delete 30 GB of cache files, restart, and System Data still shows the old number. Two things help.

First, the Storage pane caches its own results. You can force a refresh by closing System Settings completely (Cmd+Q, not just the close button) and reopening it.

Second, the Spotlight metadata daemon mds is what feeds size data to Storage. If mds is mid-rebuild (after a major macOS update, for example) the numbers can be off by tens of gigabytes. Check whether indexing is active:

mdutil -s /

If it says “Indexing enabled,” let it finish before trusting the Storage pane.

There’s a faster waySweep does this kind of cleanup automatically. Try Sweep free →

The Time Machine Snapshot Trap

If your System Data is consistently massive — say, 80+ GB on a machine that hasn’t accumulated that much real data — local Time Machine snapshots are the most likely culprit.

These snapshots get cleaned up automatically when:

  • You back up successfully to your Time Machine destination
  • Free space drops below ~20%
  • They age past 24 hours

But if you’ve been disconnected from your backup drive for weeks, snapshots pile up. To force-thin them:

tmutil thinlocalsnapshots / 10000000000 4

That tells tmutil to remove snapshots until at least 10 GB of free space is recovered, with urgency level 4 (highest). Adjust the number to match what you need.

You can also disable local snapshots entirely on the boot drive with sudo tmutil disable, but that breaks Time Machine’s “go back to a moment yesterday” feature even when your backup drive is connected.

Photos and Messages: The Hidden Gigabytes

Two Apple apps deserve special mention because they’re notorious for inflating System Data.

Photos with iCloud Photo Library + “Optimize Mac Storage” keeps a rolling cache of full-resolution images locally. The cache size depends on free disk space — when the system is tight, it shrinks; when it’s roomy, it expands aggressively. There’s no setting to cap it. Turning Optimize off and back on triggers a recalculation.

Messages stores attachments at ~/Library/Messages/Attachments. If you’ve been on iMessage for a decade, this folder can be enormous. You can browse it directly:

du -sh ~/Library/Messages/Attachments

Most people have multiple gigabytes here, often pushing into the tens. Messages itself doesn’t surface a “clear old attachments” option — you’d manually delete conversation threads in the app.

When System Data Won’t Shrink

You’ve cleared caches, killed snapshots, deleted derived data, and System Data is still 60 GB. A few less-obvious causes:

  • Active processes holding deleted files open — A file marked deleted but still in use by a running process doesn’t free its space until that process releases the handle. Restart can fix this.
  • APFS snapshots from third-party backup software — Carbon Copy Cloner, SuperDuper!, and similar tools take their own snapshots. Check diskutil apfs listSnapshots /.
  • Trash on external volumes — Items deleted from a connected drive go to .Trashes/<UID> on that drive but count against your boot volume in some Storage views.
  • Mail’s full-text search index — At ~/Library/Mail/V10/MailData/Envelope Index. Can hit 10+ GB on heavy email accounts.

What This Means in Practice

System Data isn’t mysterious once you know its parts. The categorizer is just lazy and the system is aggressive about caching. On a 1 TB Mac, 100 GB of System Data is probably fine. On a 256 GB Mac, it’s almost certainly hiding 50+ GB of stuff you don’t need.

The goal isn’t to drive System Data to zero — that’s not even possible. It’s to know what’s in there, clear out the genuinely safe-to-clear pieces (caches, logs, derived data, old backups), and recognize when an app’s footprint has grown out of proportion. Most of the time, that’s all you need.

← Back to all guides