What is System Data on a Mac, and why won't it shrink?

"System Data" is Apple's catch-all bucket in System Settings > General > Storage for everything that doesn't fit its other categories — app caches and logs, Time Machine's local snapshots, Docker's virtual disk, old iPhone backups, and a few virtual-memory files macOS manages entirely on its own. It resists shrinking on command because most of what's inside it isn't a folder you're supposed to delete by hand: some of it (caches) really is safe to clear yourself, and some of it (snapshots, purgeable space) macOS reclaims on its own schedule, when it decides the room is actually needed. Below is what's really in the bucket, the exact commands for checking each piece, and the order to work through it in when the number won't budge.

What macOS actually calls "System Data" (and where the label came from)

Apple's own description of the category, on its current Storage settings page, amounts to: files that don't fall into any of the categories listed above it — mainly log files, caches, VM files, and other files the system itself uses while running (see Apple's guide to changing Storage settings). That's the whole definition. It isn't one folder, one process, or one thing you fix — it's whatever's left over once macOS has already counted your Applications, Documents, Photos, Mail, and everything else it can name.

The label itself is newer than most people assume. Through macOS Big Sur (11), this bucket was called "Other," with a separate "System" line for the OS itself. Somewhere around Monterey (12) and Ventura (13), Apple renamed it "System Data" and split out a dedicated "macOS" category for the operating system proper — same pile of leftovers, a clearer label. If you're on Sonoma (14), Sequoia (15), or the current Tahoe release, you're looking at that same "System Data" framing; Tahoe is macOS 26, not macOS 16 — Apple jumped its version number from 15 straight to 26 in 2025 to line the Mac up with iOS, iPadOS, and the rest of its platforms, which trips up a lot of searches for "macOS 16 storage." The Liquid Glass redesign in Tahoe changed how the Storage pane looks, not what it counts.

You'll find it at Apple menu > System Settings > General > Storage, or the older muscle-memory route, Apple menu > About This Mac > Storage > Manage, which lands on the same screen.

What's actually inside the System Data bucket

The name tells you nothing useful on its own, so here's what's consistently filed under it, with real paths.

Time Machine local snapshots — the one item that's both biggest and most misread

Apple's own explanation is specific: local snapshots are hourly copies of changed files, kept on the same disk as the originals (not the backup drive) for up to 24 hours or until the disk needs the space, whichever happens first (Apple: About Time Machine local snapshots). Their entire job is letting you recover a recent file version, or restore from Time Machine, even when your backup drive isn't plugged in. A Mac carrying a chunk of System Data for snapshots isn't leaking space — it's evidence Time Machine is doing exactly what it's designed to do.

They're also the item every "clear your System Data" list reaches for first, and there's a real reason: Mac technical writer Howard Oakley has documented Macs where snapshots alone account for hundreds of gigabytes — "the current record is over 400 GB," he wrote in October 2025 — usually because a large virtual machine or dataset got backed up, excluded, then re-included, with snapshots quietly retaining every version along the way (Eclectic Light Company, October 2025).

You can see your own list without touching anything:

tmutil listlocalsnapshots /

That prints every snapshot currently held on your boot volume, by date. It's read-only — running it changes nothing on disk.

Why the number moves on its own — and why Finder disagrees with the Storage pane

Two different places on the same Mac report on the same disk using two different definitions of "free," and that's most of the disagreement.

Storage settings counts actual bytes used and actual bytes free. Finder — and the "Available" figure shown in several other places in macOS — adds in APFS purgeable space: data the filesystem has flagged as safe to remove automatically the moment something else needs the room, but hasn't removed yet. That covers cached copies of files optimized to iCloud, snapshot data waiting to be thinned, and similar. It's real, currently occupied disk space that macOS is confident it can reclaim on demand, so it gets counted as available before it's actually gone.

The gap between the two numbers can be sizable, and it isn't a rounding error. Oakley's own testing with Mints, his APFS-inspection utility, found one Mac reporting 227.83 GB "available" in Finder, including 83.71 GB flagged purgeable — but only 144.12 GB genuinely free once you accounted for what was still, in practice, occupied (Eclectic Light Company, April 2023). Finder isn't wrong; it's answering a more optimistic question than "how much room do I actually have right now."

A few concrete reasons the figure shifts without you doing anything:

• Right after a macOS update or upgrade. Installers leave temporary support files behind that clear automatically over the following 24 to 48 hours — check again the next day before assuming anything's stuck.
• Time Machine just ran. A fresh hourly snapshot briefly adds to the total; an older one aging out or getting thinned briefly subtracts from it.
• Something is genuinely stuck, less often. In August 2025, reader reports collected on Michael Tsai's blog described a real edge case on Tahoe betas: Spotlight's indexing process (mds_stores) stuck in a loop, with one Mac showing 383.94 GB under System Data while a full admin-level scan of the actual files on disk found only around 90 GB (Michael Tsai, August 2025). That's rare, and it's a Spotlight problem wearing a System Data costume — not the default explanation — but if your number is wildly out of proportion to everything above, it's worth ruling out before you touch anything else.

The commands that actually tell you something

Three commands cover almost everything worth checking by hand. None of them require guessing.

See what a folder is really using:

du -sh ~/Library/Caches/* 2>/dev/null | sort -rh | head -10

Lists the ten largest per-app cache folders, biggest first. Swap the path for ~/Library/Logs, ~/Library/Developer/Xcode/DerivedData, or ~/Library/Developer/Xcode/iOS DeviceSupport (quote the path — the folder name has a space in it) to check those the same way. For Docker's disk image specifically:

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

List your Time Machine local snapshots:

tmutil listlocalsnapshots /

Read-only, as above. Worth running before you decide snapshots are the problem, not after.

Ask macOS to thin snapshots, rather than force-deleting one:

sudo tmutil thinlocalsnapshots / 10000000000 4

That asks macOS to free roughly 10 GB from local snapshots at maximum urgency (the last number, 1–4). It lets macOS choose which snapshots to remove using the same logic it already runs automatically under real space pressure — this is the sanctioned way to nudge the process along, not a workaround.

tmutil deletelocalsnapshots <date> (paired with a date from listlocalsnapshots) force-removes one specific snapshot outright. It's a real, Apple-shipped subcommand, and it works — but understand the cost: that snapshot's restore points are gone the moment the command finishes, with no undo, and if you delete the only recent one right before you need it, Time Machine can't hand you a version of a file you changed since. Reach for thinning first. Reach for deleting a specific snapshot only when you know exactly which one and why.

Ordered troubleshooting: what to check when System Data genuinely won't shrink

1. Wait a day, especially right after an update. If you just installed a macOS update, or Time Machine just finished a backup, give it 24–48 hours before treating the number as stuck. Most "why is my Mac suddenly full" spikes settle on their own in that window.
2. Check Time Machine snapshots first — they're the most common real cause. Run tmutil listlocalsnapshots /. A long list stretching back further than a day or two, or a Mac where a large excluded folder was recently included in a backup, points here.
3. Check Docker, if you have it installed. Open Docker Desktop's Settings > Resources > Advanced, or run du -sh on Docker.raw directly (path above). It grows toward its configured limit and rarely shrinks without you telling it to (see Docker's own disk-usage docs).
4. Check for old iPhone or iPad backups. Connect the device in Finder, or check ~/Library/Application Support/MobileSync/Backup directly — a backup for a phone you no longer own, or one that's also synced to iCloud, is dead weight.
5. If you're a developer, check DerivedData and DeviceSupport. These two alone can hold 20–40 GB after a couple of years of iOS work across several devices — see our guide to clearing Xcode, node_modules, and Docker caches for the full rundown, including the cases that aren't as simple as these two.
6. Rule out a stuck background process last, not first. Open Activity Monitor and sort by CPU. If mds_stores or mdworker has been pinned high for well over an hour with nothing obviously running, that's the Spotlight edge case above — the fix is usually a restart, or sudo mdutil -E / to force a clean reindex, not deleting files.
7. After all of that, treat the remainder as normal. A gap between what you can account for by hand and what Storage reports is expected — purgeable space and snapshot bookkeeping alone can explain tens of gigabytes, per the numbers above.

When a big System Data number is completely normal

Most guides on this topic treat every large System Data figure as a problem waiting for a fix. It often isn't.

• You back up locally with Time Machine. Local snapshots existing at all — sometimes several gigabytes' worth — means the feature is working as designed, not that something's wrong.
• You're a developer. Xcode, Docker, a few years of connected test devices, and a couple of package-manager caches each keep their own storage. A working developer Mac carrying 40–60 GB of System Data is ordinary, not bloated — periodic cleanup is the fix, not alarm.
• You just upgraded macOS. Expect a real, temporary spike for the first day or two while installer support files finish clearing on Apple's own schedule.
• Your Mac still has plenty of free space regardless. If Storage shows 150+ GB available on a 512 GB drive, a large System Data slice isn't costing you anything you're currently using.

The number worth acting on is available space, not System Data size in isolation. A Mac with 40 GB in System Data and 200 GB free doesn't need intervention; one with 5 GB free does, regardless of which category that used space sits in.

If the actual complaint is that the Mac feels slow rather than just full, that's usually a separate problem — see our take on whether a RAM cleaner actually helps before assuming storage is the cause.

Skip the generic "sudo rm -rf" advice

Search around and you'll find Terminal one-liners for clearing System Data that treat every path the same way: sudo rm -rf, pointed at whatever folder is currently annoying you. That's the wrong mental model, and it's worth being specific about why instead of just saying "be careful."

Two of the folders in the table above — ~/Library/Developer/Xcode/DerivedData and ~/Library/Developer/Xcode/iOS DeviceSupport — really are fine to remove with rm -rf from Terminal. They're pure build and debug artifacts, Xcode owns rebuilding them completely, and nothing else on the system reads them.

Almost everything else covered here isn't in that category. Time Machine's local snapshots aren't ordinary files you can rm — they're APFS snapshot metadata, and tmutil is the only supported door in. System Integrity Protection blocks direct access to plenty of the rest, sudo or not. And even where a delete would technically succeed (a Docker.raw file while Docker Desktop is running, an app's Application Support folder that also holds your real settings), a raw filesystem delete skips the Trash, skips any confirmation, and skips whatever checks would normally protect a file another process still has open. Move things to Trash when you have that option. Use the tool built for the specific case instead: tmutil, Docker's own settings, or Finder's backup manager.

Where SwoopByte Disk fits

This is the exact gap SwoopByte Disk is built to close: turning "System Data is 61 GB" into a named, itemized breakdown instead of one opaque number. The free version scans your disk and names the actual occupants — Time Machine local snapshots, Docker's disk image, stale iOS/iPadOS backups, app caches and logs — each with a real size, plus a free-space verdict that accounts for APFS purgeable space rather than repeating Finder's more optimistic number without explanation. None of that breakdown is paywalled.

The reclaim actions are the one-time $14.99 Pro upgrade: batch dev-cache cleanup, duplicate-file removal, scan history so you can see what actually grew since last time, and scheduled auto-swoops with low-space notifications. Everything Disk removes goes to the Trash, with exactly one documented exception: releasing Time Machine local snapshots lives in its own confirmation sheet, states plainly that it can't be undone, and never touches your Time Machine backup disk itself. We'd rather say that outright than bury it in fine print.

SwoopByte Disk is in development for Apple Silicon Macs running macOS 14 or later. Join the waitlist to get it first.

FAQ

What is System Data on a Mac?

System Data is Apple's label, in System Settings > General > Storage, for files that don't fit its other categories — mainly caches, logs, Time Machine's local snapshots, Docker's disk image, and virtual-memory files macOS manages itself. It isn't one folder or one problem; it's whatever's left over once everything else has been counted.

Is it safe to delete System Data on a Mac?

Parts of it are safe to clear yourself — app caches, logs, Mail downloads, Xcode's DerivedData, and iOS DeviceSupport. Other parts, like Time Machine local snapshots, APFS purgeable space, and sleep image and swap files, aren't meant to be deleted directly; macOS manages those on its own or through a specific tool like tmutil.

Why does System Data keep growing back after I clear it?

Because most of it regenerates by design. Caches rebuild the moment an app needs them again, Time Machine creates a new local snapshot every hour it runs, and Docker's disk image grows again the moment you pull a new image. Clearing it is routine maintenance, not a one-time fix.

Why does Finder show more available space than System Settings does?

Finder's "Available" figure includes APFS purgeable space — data macOS has flagged as reclaimable on demand but hasn't actually removed yet. That's real, currently occupied disk space being counted as if it were already free, which is why the two numbers can disagree by tens of gigabytes on the same Mac.

Can I delete Time Machine local snapshots manually?

Yes, through tmutil — tmutil listlocalsnapshots / to see them, and sudo tmutil thinlocalsnapshots to ask macOS to free space from them. Don't reach for a Finder or Terminal rm; snapshots aren't ordinary files, and macOS already thins them automatically once it needs the room.

Why is System Data suddenly huge right after installing a macOS update?

Update installers leave temporary support files behind that macOS clears automatically, usually within 24 to 48 hours. Check again the next day before troubleshooting further — most post-update spikes resolve on their own.

Related guides