Why is System Data so big on my Mac?

System Data is the catch-all for anything Storage settings can't assign to a named category. On developer Macs that usually means Time Machine local snapshots, Docker or other VM disk images, hidden caches like ~/.npm and ~/.cache, simulator runtimes, swap files and logs.

Is it normal for Mac System Data to be over 100 GB?

It is common on Macs used for development, but it is rarely necessary. Local snapshots, a Docker disk image and a few simulator runtimes can each add many gigabytes, and all of them can be reduced safely.

Can I delete System Data on Mac?

Not as a single item, and you should never delete folders under /System or /private/var by hand. You shrink System Data by removing the things inside it, such as old snapshots, caches, Docker data and unused simulator runtimes, with the tools that own them.

Why does System Data go down after a restart?

Swap files and some temporary caches are released on restart, and macOS may thin local snapshots and purge caches when it needs space. That is why the number fluctuates even if you delete nothing.

Mac System Data Too Large? How to Shrink It

Mac System Data is too large when Storage settings dumps everything it can’t categorize into one bucket: Time Machine local snapshots, Docker and VM disk images, hidden developer caches, simulator runtimes, swap and logs. You can’t delete “System Data” itself, but you can shrink it by removing the biggest pieces with the tools that own them.

TL;DR

Check snapshots first: tmutil listlocalsnapshots /
Find the big hidden folders: du -hd1 ~/Library 2>/dev/null | sort -h | tail -10 and du -sh ~/.[!.]* 2>/dev/null | sort -h | tail -10
Shrink the usual suspects: Docker data, simulator runtimes, ~/.npm, ~/Library/Caches
Never rm anything under /System, /private/var/vm or /private/var/db.
Restart once after cleaning; the number usually drops further.

What is System Data on a Mac?

Open System Settings > General > Storage and you see a colored bar split into categories: Applications, Documents, Developer, macOS, Trash and so on. System Data is the grey segment for everything else. macOS’s own description says it “includes caches, logs and other resources currently in use by the system,” and that the value fluctuates.

In practice “everything else” is broad. Storage settings recognizes specific kinds of data, such as apps, documents, mail, photos and the Developer items Xcode registers. Anything it does not recognize, including most hidden folders and large disk images, lands in System Data. That is why it can be the largest segment on a developer Mac even though “the system” itself is a fraction of it.

Why is System Data so big on a Mac?

These are the usual contributors, roughly in order of how often they are the culprit on a developer machine.

Time Machine local snapshots

When Time Machine is on, macOS saves local snapshots of your startup disk about once an hour. Apple’s documentation says each one is kept for 24 hours, plus a snapshot of your last successful backup that is kept until space is needed. Snapshots hold on to the blocks of files you have since deleted, so deleting files may not free space until the snapshot goes away. Check with:

tmutil listlocalsnapshots /

If you see a list of com.apple.TimeMachine... entries, read how to delete Time Machine local snapshots and purgeable space.

Docker, Colima and other VM disk images

Docker Desktop stores every image, container, volume and build cache in one file, Docker.raw, under ~/Library/Containers/com.docker.docker. Colima, OrbStack, UTM and similar tools keep their own VM disks, either in dot folders such as ~/.colima or in their app containers. These are single, very large files that Storage settings doesn’t recognize, so on most setups they count toward System Data. See Docker.raw huge on Mac for how to shrink it safely.

Hidden developer caches and toolchains

Package managers and toolchains write to dot folders in your home directory: ~/.npm, ~/.cache, ~/.gradle, ~/.rustup, ~/.cargo, ~/.android and more. They are invisible in Finder and add up quickly. Add ~/Library/Caches, where Homebrew, pnpm, pip and Swift Package Manager keep downloads, and you have tens of gigabytes that nothing labels for you. Our Library caches guide covers each one.

Simulator runtimes

Recent Xcode versions install simulator runtimes as disk images managed by the system rather than inside Xcode.app. On the Mac this guide was tested on, the iOS runtime image lives under /System/Library/AssetsV2 and is mounted under /Library/Developer/CoreSimulator/Volumes. List them with:

xcrun simctl runtime list

Each runtime is several gigabytes. Old ones from previous Xcode versions are a common source of silent growth. See how to delete Xcode simulators.

Swap, sleep image and logs

macOS uses swap files when memory is tight and, on laptops, a sleep image for hibernation. On recent macOS the swap files live on a separate VM volume, and the sleep image is in /private/var/vm. System logs and diagnostics live under /private/var/db/diagnostics and /private/var/log. These are all managed by macOS. They can be several gigabytes, but you should not delete them by hand; they shrink on their own, especially after a restart.

Other system assets

macOS downloads assets on demand, such as fonts, language data, developer documentation and, on supported Macs, on-device model data. They live in system locations like /System/Library/AssetsV2. Recent versions of Storage settings list some of these separately (for example, an Apple Intelligence category), and others stay in System Data. They are managed by macOS; leave them alone.

Mac system data over 100 GB: what is usually behind it

When System Data passes 100 GB, it is rarely one thing. On a developer Mac it is usually a combination: a Docker disk image full of old images and build cache, a few simulator runtimes from previous Xcode versions, years of ~/.npm and other package caches, and a day’s worth of local snapshots holding on to files you deleted recently. Each is reasonable on its own. Together they look like a problem with macOS.

How to see what is inside System Data

Storage settings won’t break System Data down. Terminal will. Run these read-only commands and look at the last lines, which are the largest:

# Hidden usage in your Library folder
du -hd1 ~/Library 2>/dev/null | sort -h | tail -10

# Hidden dot folders in your home directory
du -sh ~/.[!.]* 2>/dev/null | sort -h | tail -10

# Biggest app containers (Docker Desktop lives here)
du -sh ~/Library/Containers/* 2>/dev/null | sort -h | tail -5

# Local snapshots
tmutil listlocalsnapshots /

# Simulator runtimes
xcrun simctl runtime list

# Current swap usage
sysctl vm.swapusage

If du prints “Operation not permitted” for some folders, macOS privacy protection is blocking Terminal. Grant Terminal Full Disk Access in System Settings > Privacy & Security > Full Disk Access if you want complete numbers.

For a system-wide view, you can run du with sudo against the data volume, staying on that volume with -x:

sudo du -xhd1 /System/Volumes/Data 2>/dev/null | sort -h | tail -10

This takes a while on a large disk and is only for reading. Do not follow it with sudo rm on anything it shows outside your home folder.

How to reduce System Data safely

Work through this list from top to bottom, checking the size before each step.

What	Where	Safe to delete?	How to remove it
Local snapshots	APFS snapshots of `/`	Yes, you lose hourly restore points	`tmutil deletelocalsnapshots` (see snapshot guide)
Docker data	`Docker.raw`	Only through Docker	`docker system prune`, then Docker’s disk settings
Simulator runtimes	`xcrun simctl runtime list`	Yes for versions you don’t test	`xcrun simctl runtime delete` (supports `--dry-run`)
npm cache	`~/.npm`	Yes	`npm cache clean --force`
Other package caches	`~/Library/Caches`, `~/.cache`	Yes	Each tool’s clean command
App caches	`~/Library/Caches/<app>`	Yes, with the app quit	Delete that app’s folder
Swap, sleep image	`VM` volume, `/private/var/vm`	No	Restart; macOS manages them
Logs and diagnostics	`/private/var/db/diagnostics`	No	macOS rotates them

A few notes on the safe items:

Snapshots also come back as Time Machine keeps running. Deleting them is a one-time fix for when you need space now.
Docker.raw is a sparse file, so ls -lh shows its maximum size, not what it really uses. Compare du -sh with du -Ash on the file before deciding it is the problem.
Caches regenerate. Expect a slower first build or install afterwards, not lost data.

What you should not delete

Some guides suggest deleting folders under /private/var or /Library wholesale. Don’t. In particular:

The system snapshot. diskutil apfs listSnapshots / shows a com.apple.os.update-... snapshot marked “Purgeable: No”. It is part of how macOS boots from a sealed system volume. It is not a Time Machine snapshot and it is not yours to delete.
/private/var/vm and the VM volume. Swap and the sleep image are in use while the Mac is running.
/private/var/db and /private/var/folders. Databases and per-user temporary directories that running apps depend on. macOS cleans the temporary parts itself.
/System/Library/AssetsV2. System-managed downloads. Remove simulator runtimes with xcrun simctl runtime delete, not by deleting the files.

Why does System Data shrink by itself?

System Data is a moving number. Restarting releases swap files and some temporary caches. When free space runs low, macOS thins local snapshots and purges caches it considers expendable. That is why you can see System Data drop by many gigabytes after a reboot, or rise again over a busy day of builds. If it keeps returning to the same large size, the cause is one of the persistent items above, usually Docker or caches.

Do it in one click with DevCleanup

DevCleanup’s Overview shows how much each source can free (caches, simulators, Docker, projects, AI models and more) before you delete anything. The System Data screen covers the macOS-owned part of the grey bar: Time Machine local snapshots, iPhone and iPad backups, old macOS installers and firmware files, plus how big swap and the sleep image are. Smart Clean clears caches and logs, and the Docker and Simulators screens handle the two biggest developer contributors through the tools that own them (simulators are removed with xcrun simctl). On the developer screens, sizes are real space, with APFS clones and hard links not double counted. Every action is logged in History.

Download DevCleanup. Scanning is free; Pro ($29 one-time) unlocks the developer cleanup actions. For the full picture beyond System Data, see how to free up space on Mac as a developer.