Which caches are safe to delete on a Mac
· 6 min read
In principle, anything inside a folder called Caches can be deleted: a cache is by definition something an app can rebuild. In practice a few apps park real data in there, the space usually refills within days, and macOS already clears a lot of it on its own. So the short answer is yes, and the useful answer is that only a handful of caches are large enough to be worth your attention.
Here is which ones those are, and which ones look like caches and are not.
The four places caches live
~/Library/Caches is yours. Open it with Finder’s Go menu, Go to Folder (Command-Shift-G). Deleting things here affects only your user account and never needs an administrator password.
~/Library/Containers/<app>/Data/Library/Caches is where sandboxed apps keep theirs, and on a modern Mac this is where a lot of the real volume hides. If ~/Library/Caches looks disappointingly small, this is why.
/Library/Caches (no tilde) is system-wide and shared between accounts. Mostly safe, requires an admin password, and rarely the source of a storage problem.
/System/Library/Caches is on the sealed, signed system volume. It is read-only, you cannot delete it, and you should not try.
To find the large ones rather than guessing:
du -sh ~/Library/Caches/* 2>/dev/null | sort -h | tail -20
du -sh ~/Library/Containers/*/Data/Library/Caches 2>/dev/null | sort -h | tail -20
The ones that genuinely pay
Developer build caches. On a Mac used for building software these dwarf everything else on this page. Xcode’s DerivedData, simulator runtimes and device support folders regularly run to tens of gigabytes. Xcode is eating the disk covers what each one costs to delete.
Package manager caches. Downloaded tarballs and wheels from the usual command line package managers accumulate indefinitely and are re-fetched on demand. Each tool has its own cleanup command, and using the tool’s own command is better than deleting its folder, because it knows what is still referenced.
Browser caches. Sizeable, and clear them from the browser rather than by deleting a folder, so you keep your cookies and stay signed in. In Safari, enable the developer features in Settings, Advanced, then use the Develop menu’s Empty Caches. Other browsers have an equivalent in their own settings, usually with a checkbox that separates cached files from cookies and history. Uncheck everything except cached files.
Quick Look thumbnails, if Finder previews have gone strange:
qlmanage -r cache
Font caches, only when fonts are actually misbehaving, never as routine cleanup:
sudo atsutil databases -remove
Restart afterwards. This one is a repair, not a space saving.
The ones that look safe and are not
Offline downloads that live in a cache folder. Media apps, podcast clients and file sync clients quite often keep downloaded content under Caches because that is the folder the system offers them. Deleting it is technically harmless and practically means re-downloading gigabytes over a connection you may not have. If a cache folder is suspiciously large for an app you use offline, open the app’s own settings and look for a storage or downloads section first.
Mail’s envelope index. It sits in the Mail folder, not in Caches, and it is not disposable in the same sense: rebuilding it on a large mailbox takes a long time and the Mac is close to useless while it happens. Leave it unless you are fixing a specific search problem.
Anything inside the Photos library. The library holds originals, thumbnails and derivatives in one package and manages its own storage. Reaching inside it with Finder or Terminal is how people lose photographs.
Anything in Application Support. It sits next to Caches in the same Library folder and holds licenses, databases, app settings and in some cases the only copy of your work. The names look similar. They are not the same category of thing.
And a general rule: never run sudo rm -rf against a path you typed from memory. In your own Library, rm without sudo is enough for anything you legitimately want gone, and dragging to the Trash is better still.
How to do it without regret
- Quit the app whose cache you are clearing. An app that is running may rewrite the folder as you delete it, or crash.
- Sort by size and work from the top. Two or three folders will account for nearly all of it.
- Delete the contents of a cache folder rather than the folder itself. Most apps recreate either, some are fussier about the folder.
- Drag to the Trash instead of deleting outright.
- Use the Mac normally for a day, then empty the Trash. If something broke, you can put it back.
Why the space comes back
Caches exist because the alternative is recomputing something expensive. Delete them and the apps rebuild them, which is the system working as designed rather than a problem.
macOS also handles a good deal of this without being asked. A large amount of cache space is marked purgeable, and when the disk gets genuinely tight the system reclaims it automatically. That is why clearing caches so rarely fixes a Mac that is persistently full: the disk was already reclaiming what it could, and the tens of gigabytes you are looking for are somewhere else. Usually old device backups, a virtual machine disk image, or a developer folder.
This is the case for auditing before deleting. A read-only pass with something like Crumb breaks System Data into its parts (caches, logs, swap, temporary files and leftovers) and its Ask Crumb feature will tell you what a specific item is, whether it regenerates, and what stops working if it is gone, before anything is removed. Nothing is deleted until you approve the plan, and reclaimable removals can be reviewed afterwards. The du commands above get you most of the same picture if you would rather do it yourself.
If the audit points at a virtual disk rather than caches, Docker.raw is huge on a Mac explains why the number in Finder is usually not the real one. If it points at device backups, find and delete old iPhone backups covers that.
Questions
Does clearing caches speed up a Mac? No, and for the first day it makes things slightly slower, because everything that was cached has to be recomputed. Clearing a specific app’s cache is a reasonable troubleshooting step when that app is behaving oddly. As general maintenance it achieves nothing.
Do I need Full Disk Access for any of this?
For ~/Library/Caches, no. Terminal needs Full Disk Access to reach some protected locations, and Finder will ask for an administrator password before touching /Library. If a command returns a permissions error, that is usually what it is telling you: System Settings, Privacy and Security, Full Disk Access.
Should I set this up to run automatically? Rarely worth it. A scheduled job that deletes caches every night guarantees the slow rebuild every morning for a saving the system would have made for you under pressure. The exception is developer build output, which is genuinely large, genuinely disposable, and worth clearing on a schedule you choose.
What about a Caches folder for an app I deleted months ago? That one is pure leftover and safe to remove, since nothing will ever rebuild it. The same is true of orphaned preference files and support folders from uninstalled apps, which is a good argument for removing apps properly rather than dragging the icon to the Trash and moving on.