If you have opened Apple menu → System Settings → General → Storage and watched the "System Data" bar swallow most of your disk, you are not alone. System Data is a catch-all bucket for anything macOS cannot classify elsewhere, which means the label hides a surprising variety of culprits. Below are the nine most common causes, ranked roughly from most frequent to least, so you can work through them in order.
What counts as "System Data" on macOS?
On macOS Ventura and later, the Storage overview splits your drive into categories like Applications, Documents, Photos, and System Data. System Data covers:
- Caches (browser, system, app)
- Log files
- Temporary files and swap
- Time Machine local snapshots
- iOS/iPadOS device backups and software update caches
- Virtual machine disk images
- Hidden app support data that macOS cannot attribute to a specific app
Because the category is so broad, a single culprit can be responsible for tens of gigabytes without any obvious warning.
1. Time Machine local snapshots (most common cause)
When a Time Machine backup drive is unavailable, macOS quietly stores local snapshots on your startup disk. These can accumulate to 50 GB or more on a MacBook used away from its backup drive for weeks at a time.
Check how much space snapshots are using:
tmutil listlocalsnapshots /
tmutil listlocalsnapshotdates /To delete all local snapshots:
tmutil deletelocalsnapshots /Risk level: safe. macOS recreates snapshots automatically when it has spare space. Deleting them does not affect your off-site Time Machine backup.
2. System and application caches
Every app that processes media, compiles code, or renders UI writes cache files so it does not have to repeat that work. After months of use these build up in:
~/Library/Caches— per-user app caches/Library/Caches— system-wide caches/private/var/folders/— temporary caches macOS manages internally
Check your user cache size:
du -sh ~/Library/CachesRisk level: generally safe, though deleting caches can slow apps down temporarily while they rebuild. Never delete caches while the owning app is open.
3. iOS and iPadOS device backups
Every time you back up an iPhone or iPad to your Mac through Finder, macOS stores a full device backup in ~/Library/Application Support/MobileSync/Backups/. A single iPhone backup can be 10–30 GB; multiple devices or multiple backup generations multiply that quickly.
To manage them: open Finder → select your device → Manage Backups. Delete backups you no longer need.
Risk level: permanent. Deleting a backup means you cannot restore from it. Keep at least one recent backup per device.
4. System log files
macOS and third-party daemons write diagnostic logs to /var/log/, ~/Library/Logs/, and the unified logging store at /private/var/db/diagnostics/. On a machine with a crash-looping daemon or verbose logging enabled, this directory can grow several gigabytes per day.
du -sh ~/Library/Logs
sudo du -sh /var/logRisk level: safe to delete most log files. macOS recreates them. Do not delete the entire /var/db/diagnostics/ directory—use log erase --all instead if you need to clear the unified log store.
5. Xcode and developer data
Xcode is notorious for leaving behind gigabytes of derived data, simulator runtimes, and device support files even after you delete a project. The usual locations:
~/Library/Developer/Xcode/DerivedData~/Library/Developer/Xcode/iOS DeviceSupport~/Library/Developer/Xcode/watchOS DeviceSupport~/Library/Developer/CoreSimulator/Caches
From within Xcode: Settings → Locations → Derived Data → Delete. For simulator caches, run:
xcrun simctl delete unavailableRisk level: safe to delete derived data and old device support files. Xcode will regenerate what it needs.
6. Large language model and AI tool caches
Local AI tools—Ollama, LM Studio, and others—download multi-gigabyte model weights to ~/.ollama/models or ~/Library/Application Support/LM Studio/. macOS cannot categorize these as "Documents," so they land in System Data. A single 7B model can be 4–8 GB; 70B models can exceed 40 GB.
Check your Ollama model directory:
du -sh ~/.ollama/modelsRemove models you no longer use from the tool's own interface, or run ollama rm model-name.
Risk level: safe, but models must be re-downloaded if you want them back.
7. Virtual machine disk images
VMware Fusion, Parallels, and UTM store disk images that grow dynamically and rarely shrink on their own. A Windows 11 image might start at 30 GB and reach 80 GB after updates. These images live wherever you saved them—often the Desktop or Documents folder—but macOS may still classify the associated snapshots and suspension files as System Data.
Compact your VM from the hypervisor's own tools before considering deletion.
Risk level: high. Only delete VM images you no longer need. There is no recovery after deletion.
8. Safari and browser caches
Safari stores its cache at ~/Library/Caches/com.apple.Safari/; Chrome uses ~/Library/Caches/Google/Chrome/; Firefox keeps its cache under ~/Library/Caches/Firefox/Profiles/. Heavy video streaming, development work with browser DevTools, or simply leaving a browser open for weeks can push these into multiple gigabytes.
Clear from within the browser (Safari: Develop → Empty Caches; Chrome: Settings → Privacy → Clear browsing data).
Risk level: safe. Websites will reload images and scripts on the next visit, but no personal data is lost.
9. Purgeable space miscounted as System Data
macOS occasionally presents "purgeable" space—files it can delete on demand, like iCloud stubs, optimized storage placeholders, and cached media—inside the System Data bar. This is largely cosmetic: macOS reclaims it automatically when apps need room. If your total free space looks adequate despite a large System Data figure, purgeable space may be inflating the number.
Check actual vs. purgeable space:
diskutil info / | grep -E "Free Space|Purgeable"How to find your specific culprit
The challenge with "why is system data so large on Mac" is that it is almost never just one thing. The fastest way to isolate the real cause is a whole-disk size breakdown rather than guessing folder by folder.
- Open Terminal and run
du -sh ~/Library/* | sort -rh | head -20for a quick per-folder snapshot in your home Library. - For system-level directories, repeat with
sudo du -sh /Library/* | sort -rh | head -20. - Cross-reference with the Storage overview in System Settings to see whether the number drops after cleaning each category.
If you prefer a visual approach, Crumb includes a whole-Mac audit that maps every folder on your disk by size, highlights the largest items, and flags common bloat categories—including the Time Machine snapshots, cache directories, and developer data described above—so you can see at a glance which culprit actually accounts for your missing gigabytes.
What is safe to delete vs. what is not
| Category | Safe to delete? | Rebuilt automatically? |
|---|---|---|
| Time Machine local snapshots | Yes | Yes |
App caches (~/Library/Caches) |
Generally yes | Yes, by the app |
| System logs | Yes | Yes |
| Xcode derived data | Yes | Yes, on next build |
| iOS device backups | With caution | No |
| AI model weights | Yes | Only if re-downloaded |
| VM disk images | Only if unused | No |
| Purgeable space | macOS handles it | Yes |
Conclusion
System Data being huge on a Mac is almost always explainable—Time Machine snapshots and accumulated caches together account for the majority of cases. Work through the categories above in order, use du to verify which folder is the real offender, and be cautious before deleting anything that cannot be rebuilt automatically. If you want to skip the folder-by-folder detective work, download Crumb to get a visual breakdown of your entire disk and let the whole-Mac audit point you straight to the problem.