MacBook Pro System Data Too Large? Here's the Real Fix

You open About This Mac, click Storage, and there it is. A gray bar labeled "System Data" eating 80GB, 120GB, sometimes more.

Your Applications folder is 20GB. Your Documents are practically empty. Yet somehow this one mystery category is swallowing half your SSD.

I've spent more hours than I'd like to admit chasing this exact bar down on three different MacBook Pro units this year, including a base 512GB M4 Pro that ran out of space mid-project. What I found is that "System Data" isn't one thing. It's a catch-all bucket, and Apple's own storage panel is genuinely bad at explaining what's inside it.

What System Data Actually Is (And Why Apple Won't Tell You)

Apple's official line is that System Data covers anything that doesn't cleanly fit into Documents, Apps, Photos, iCloud Drive, or Mail.

That's technically true and practically useless.

In real-world terms, this category is a blend of:

• Cached files from every app you've ever opened, including Xcode, Photoshop, and your browser
• System and diagnostic logs, which grow constantly in the background
• Time Machine local snapshots, even if you've never plugged in a backup drive
• Virtual memory swap files
• Leftover files from deleted apps that never got cleaned up
• iOS and iPadOS device backups stored locally through Finder
• Docker images, Xcode DerivedData, and simulator runtimes if you're a developer

That last bullet is the one nobody talks about, and it's often the biggest single offender on developer machines. A single Xcode project with a handful of simulators can quietly stash 15 to 30GB in ~/Library/Developer.

Local Time Machine snapshots are the other silent killer. Even without an external drive, macOS takes hourly snapshots on your internal disk purely so it can roll back files if something goes wrong. These are supposed to auto-purge when you're low on space, and in my testing that promise doesn't always hold up, especially right after a big migration or macOS update.

Pro Tip: If your System Data spiked right after using Migration Assistant or restoring from a Time Machine backup, don't touch anything for the first 24 hours. macOS is mid-indexing during that window, and Spotlight's mds process temporarily inflates the System Data figure while it rebuilds its search database. I've watched a "97GB System Data" reading drop to 24GB overnight with zero manual intervention.

There's also a structural reason this category is so hard to pin down. APFS, the file system every modern Mac uses, shares storage space dynamically across every volume in a container rather than locking off fixed partitions the way older drives did.

That flexibility is great for performance, but it means the Storage panel is estimating rather than reporting a hard, static number. Two identical MacBook Pro units running the same apps can show noticeably different System Data figures purely because of when their snapshots last ran or when their caches last rotated.

The Real Numbers: What's Actually Normal

Here's the range I've settled on after checking dozens of Macs across different workloads.

A clean, freshly set up MacBook Pro on macOS Tahoe or Sequoia should sit around 12 to 20GB of System Data. That's baseline OS overhead, caches, and logs.

Once you're a few months into daily use, 20 to 35GB is completely normal for a non-developer. Creative professionals running Adobe apps or Final Cut regularly see 40 to 60GB because render caches and media previews land in this category too.

Anything past 80 to 100GB, especially if it climbed suddenly, usually points to a stuck snapshot, a runaway log file, or an app that isn't cleaning up after itself.

Chip generation matters less than people assume. An M4 Pro and an older Intel MacBook Pro accumulate System Data at roughly the same pace for identical workloads, since the bloat comes from software behavior, not silicon.

Storage tier matters more than most guides admit. Owners of the base 256GB or 512GB configurations notice System Data bloat faster simply because the same 40GB of caches represents a much bigger percentage of a smaller drive.

System Data Cleanup Methods Compared

Not every fix is worth the same amount of effort. Here's how the main approaches stack up.

Method	Best For	Setup Effort	Result Quality	Value
Manual Finder cleanup	Casual users, small buildup	Low	Moderate, misses hidden folders	Free
Terminal commands (tmutil, du)	Power users, precise diagnosis	Medium	High, targets exact cause	Free
Third-party cleaner apps	Non-technical users wanting speed	Low	Moderate to high, varies by app	Paid, $30 to $50/year
Erase and reinstall macOS	Last resort, severe corruption	High	Highest, full reset	Free but time-costly

In my experience, the terminal route gives you the best ratio of effort to actual results because you can see exactly what's taking space instead of trusting a colored bar to be honest with you.

Third-party cleaner apps aren't a scam, to be clear. Several of them do a genuinely good job scanning for duplicate files and old app leftovers.

Where they fall short is precision. Most flag broad categories like "system junk" without telling you the specific folder responsible, which means you're trusting their judgment instead of verifying it yourself.

How I Actually Diagnosed a 110GB System Data Problem

Here's the workflow I used on a MacBook Pro 14-inch that showed 110GB of System Data with only 6GB in visible Documents.

• Opened Terminal and ran du -sh ~/Library/* 2>/dev/null | sort -rh | head -20 to rank the biggest folders inside Library
• Found ~/Library/Developer/Xcode/DerivedData sitting at 22GB from old build artifacts
• Ran tmutil listlocalsnapshots / and found four snapshots dating back three months
• Checked ~/Library/Application Support/MobileSync/Backup and found a forgotten 14GB iPhone backup from a phone I no longer owned
• Ran docker system df since Docker Desktop was installed, revealing 9GB of dangling images

None of that showed up clearly in the Storage panel's breakdown. The panel just lumped it all under one gray bar and called it a day.

After clearing DerivedData, deleting the old snapshots with tmutil deletelocalsnapshots, removing the orphaned backup, and running docker system prune, the System Data figure dropped from 110GB to 31GB. No reinstall, no third-party app, just knowing where to look.

A second case, this time on a non-developer's MacBook Pro, told a different story. There was no Xcode and no Docker involved at all.

Running the same du -sh scan pointed straight at ~/Library/Caches/com.apple.Safari and a bloated Chrome profile cache sitting past 18GB combined. Years of browsing without ever clearing cache had quietly built up a small archive of every website visited.

Clearing browser caches through each app's own settings, rather than deleting the folder manually, brought that Mac down by roughly 22GB in under ten minutes. The lesson here is that the fix genuinely depends on how you use the machine, and guessing wastes far more time than a five-minute terminal scan.

If your workflow involves clearing out general junk on a regular schedule, it's worth comparing that Terminal approach against the routine covered in this guide on wiping out temp files on your Mac, since temp file buildup and System Data bloat often come from the same sources.

The Honest Limitations Nobody Mentions

I want to be straight about where this gets messy, because a lot of guides oversell how much control you actually have.

You cannot click into "System Data" the way you can click into Documents or Apps. Apple gives you zero native drill-down, which is exactly why third-party tools like DaisyDisk or OmniDiskSweeper exist as visual workarounds.

Deleting the wrong cache folder can break an app until it rebuilds that cache, which sometimes takes a noticeable performance hit the first time you relaunch it. I've had Photoshop take almost two full minutes to reopen after I nuked its cache directory.

Some of what's counted as System Data is genuinely purgeable space, meaning macOS will automatically reclaim it the moment you need room. That means the number on screen can be misleading. You might have 40GB reported as "used" that would vanish instantly if you tried to install a large file.

If multiple user accounts exist on the same Mac, some of what looks like System Data bloat is actually hiding in a separate bucket entirely. That's worth ruling out by checking how the shared storage from other user accounts gets calculated, since a forgotten guest account with old downloads can inflate your total without ever touching System Data.

And no, running a defrag utility does nothing here. APFS handles file placement completely differently than older HFS+ volumes did, which is a common misconception I still see floating around forums.

There's also a wear consideration worth knowing about. Constantly deleting and recreating large cache files puts marginally more write cycles on your SSD than leaving well-behaved caches alone.

In practice this is a non-issue for anyone doing occasional cleanup, but it's why I don't recommend scripting an aggressive daily wipe of Library folders. A monthly or bi-monthly pass is plenty for almost every use case I've tested.

Practical Setup: My Actual Cleanup Routine

This is the sequence I run every couple of months, in order, because doing them out of order wastes time.

1. Restart the Mac first. This alone flushes a surprising amount of temporary cache and kills stuck background processes.
2. Open Terminal and run sudo tmutil listlocalsnapshots / to see what snapshots exist.
3. If snapshots are old and you have an external Time Machine backup, delete them individually with tmutil deletelocalsnapshots [date].
4. Check developer clutter with du -sh ~/Library/Developer/* if you use Xcode, and clear DerivedData safely since Xcode rebuilds it automatically.
5. Review ~/Library/Application Support/MobileSync/Backup for old iPhone or iPad backups you no longer need.
6. Empty Trash from all locations, including the hidden .Trashes folder on external drives, since deleted files sometimes linger there too.
7. Clear your primary browser's cache through its own settings menu rather than deleting the folder directly, since some browsers rebuild corrupted profiles poorly if you touch the raw files.
8. Turn on Optimize Storage under System Settings > General > Storage, which automatically removes watched TV shows and movies and manages old Mail attachments going forward.
9. Reboot once more and recheck the Storage panel after letting the Mac sit idle for 15 to 20 minutes.

This entire routine takes me about 25 minutes from start to finish, most of which is just waiting on the du scan to finish crawling the Library folder.

Pro Tip: Before deleting anything Time Machine related, run tmutil thinlocalsnapshots / 10000000000 4 first instead of a full delete. This asks macOS to intelligently thin snapshots by a target byte amount rather than nuking your entire local backup history, which matters if you rely on Time Machine as your only backup method.

If you're chasing every last gigabyte because you're on a smaller SSD tier, it's also worth reading up on whether a full disk wipe is warranted versus targeted cleanup, and the tradeoffs are laid out well in this piece on whether defragmenting a Mac actually does anything, which covers a related myth about manual disk maintenance on modern SSDs.

FAQ

Is it safe to delete System Data on a MacBook Pro? Yes, but only indirectly. You're not deleting a "System Data" file, you're clearing the caches, logs, snapshots, and leftovers that get grouped into that label, and each of those is individually safe to remove.

Why did my System Data suddenly jump by 30GB overnight? The most common cause is a fresh Time Machine snapshot triggered right before a big software update, or a Spotlight reindex after installing a new drive or restoring from backup.

Will restarting my MacBook Pro actually fix a bloated System Data reading? Sometimes, yes. macOS periodically miscounts purgeable space until a reboot forces it to recalculate, and I've seen 15 to 20GB disappear from the reported total after nothing more than a restart.

Does upgrading to the newest macOS version reduce System Data size? Not directly, and it can temporarily increase it during the install process because of update caches. Long term it shouldn't make a meaningful difference either way.

Should I just erase and reinstall macOS if System Data won't go down? Treat this as a last resort rather than a first move. In my testing, fewer than one in ten stubborn System Data cases actually required a full reinstall once snapshots, DerivedData, and old backups were properly cleared out first.

Where This Is Heading

Apple has quietly improved storage transparency with every macOS release since Monterey renamed "Other" to "System Data," but the core problem remains: users still can't see inside the box without dropping into Terminal or paying for a third-party tool.

My honest read is that this won't change soon, because a messier, more granular breakdown would surface just how much space Apple's own caching and snapshot systems consume by default. The workaround isn't complicated once you know it, though. Check du, check tmutil, check your Developer folder if you code, and treat the Storage panel's gray bar as a starting clue rather than the full picture.

As base storage tiers stay smaller than the media files and dev tools people actually run, expect this exact question to keep showing up in forums for years to come. The fix stays the same regardless of which macOS version ships next: know where to look, clear the right folders in the right order, and stop trusting a single gray bar to tell the whole story.

Your MacBook Pro isn't broken. It's just keeping receipts you were never shown.