To clear cache on a Mac, first see what is actually big, then delete only that app’s cache folder while the app is closed:
du -sh ~/Library/Caches/* 2>/dev/null | sort -h | tail -10
That lists the ten largest cache folders in your user Library. Quit the app that owns the biggest one, delete that folder (or use the app’s own cleanup command, shown below), and reopen the app. It rebuilds what it needs.
I tested everything here on a MacBook Air M3 running macOS Tahoe 26.6.2. On my machine, user caches were 10 GB. I measured all of it, but I did not delete any real cache. The delete commands were tested on a fake cache folder in a scratch directory.
Step 1: See how big your caches are
Start with the total:
du -sh ~/Library/Caches
du: ~/Library/Caches/com.apple.findmy.fmipcore: Operation not permitted
du: ~/Library/Caches/com.apple.ap.adprivacyd: Operation not permitted
10G ~/Library/Caches
On my Mac this took about 24 seconds. You will also see a handful of Operation not permitted lines. I got 12 of them, including com.apple.Safari, CloudKit and com.apple.HomeKit. Those folders are protected by macOS privacy controls, so Terminal cannot read them unless you give it Full Disk Access. That is fine. It means those caches are managed by the system, and you should leave them alone anyway.
Now sort by size to find the real offenders:
du -sh ~/Library/Caches/* 2>/dev/null | sort -h | tail -10
472M ~/Library/Caches/SiriTTS
491M ~/Library/Caches/com.google.antigravity.ShipIt
530M ~/Library/Caches/com.linear.ShipIt
885M ~/Library/Caches/Homebrew
4.5G ~/Library/Caches/Google
(Output trimmed to the last five lines.) Out of 162 folders, a few apps held most of the space. That is typical. Clearing everything would gain you little more than clearing the top three or four.
The cache that most guides miss
There is a second per-user cache folder outside your home folder. macOS will tell you where it is:
getconf DARWIN_USER_CACHE_DIR
/var/folders/xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/C/
du -sh "$(getconf DARWIN_USER_CACHE_DIR)" 2>/dev/null
260M /var/folders/xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/C/
On my Mac it was 260 MB, and 8 of its subfolders were blocked with Operation not permitted. This folder belongs to system services (Spotlight, Quick Look thumbnails and similar). Do not delete it by hand. macOS manages /var/folders itself, so let the system handle it.
The system-wide /Library/Caches was only 7.1 MB here. On Apple Silicon Macs it is rarely worth touching, and changing it needs sudo.
Clear one app’s cache (the safe way)
Before you delete anything, make sure the app is not running. Apps keep cache files open. I checked Chrome while it was open:
pgrep -x "Google Chrome" >/dev/null && echo "chrome running"
lsof 2>/dev/null | grep -c "Library/Caches/Google/Chrome"
chrome running
3
Three open-file entries pointed into Chrome’s cache. Deleting them under a running app can make it crash or write half-broken data. So: quit the app with Cmd+Q first.
Then delete that one folder. For Chrome, the big part is inside each profile:
du -sh ~/Library/Caches/Google/Chrome/Default/* 2>/dev/null | sort -h | tail -3
36K ~/Library/Caches/Google/Chrome/Default/Storage
752M ~/Library/Caches/Google/Chrome/Default/Code Cache
1.4G ~/Library/Caches/Google/Chrome/Default/Cache
Every Chrome profile has its own cache. My 4.5 GB was two profiles at 2.2 GB each, so clearing only Default would have freed half. To clear one profile’s cache after quitting Chrome (not executed on my Mac):
rm -rf ~/Library/Caches/Google/Chrome/Default/Cache
Note the folder name has no spaces here. If you target Code Cache or Profile 3, wrap the path in quotes.
For Safari and other browsers, use the browser’s own setting. Safari’s cache folder was blocked for Terminal in my test, so clearing it from inside Safari is the reliable route.
What are all those ShipIt folders?
Folders ending in .ShipIt or -updater come from Electron apps (on my Mac: Linear, Notion, Claude and a few more). They hold a downloaded app update waiting to be installed:
ls ~/Library/Caches/com.linear.ShipIt
ShipItState.plist
ShipIt_stderr.log
ShipIt_stdout.log
update.JjWb9Nv
They are safe to delete when the app is closed, but the app will just download the update again. Updating the app and restarting it is usually what clears them for good.
Clear developer caches with their own commands
Package managers keep big caches, and each has a cleanup command that knows what is safe to remove. Use these instead of rm.
Homebrew. Do a dry run first:
brew cleanup -n
Would remove: /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.4 (1,579 files, 35MB)
==> This operation would free approximately 39.1MB of disk space.
Only 39 MB, even though the Homebrew cache was 885 MB. That is because plain brew cleanup keeps recent downloads. Add --prune=all to see the full amount:
brew cleanup --prune=all -n
==> This operation would free approximately 863.6MB of disk space.
That is 22 times more. When the dry run looks right, run it without -n (not executed on my Mac). Most of it was the downloads folder (775 MB), which holds old bottles Homebrew no longer needs. For more on this, see how to uninstall Homebrew packages and clean up.
npm. The cache is not in ~/Library/Caches at all:
npm config get cache
du -sh ~/.npm/_cacache
~/.npm
1.5G ~/.npm/_cacache
That 1.5 GB never shows up in the du from Step 1. To clear it (not executed): npm cache clean --force.
pip. This one is in the usual place and can report its own size:
pip3 cache info
Package index page cache location: ~/Library/Caches/pip/http
Package index page cache size: 11.4 MB
Number of HTTP files: 43
Wheels location: ~/Library/Caches/pip/wheels
Wheels size: 0 bytes
Number of wheels: 0
To clear it (not executed): pip3 cache purge.
Why rm -rf ~/Library/Caches/* is a bad idea
Many guides tell you to wipe the whole folder. I tested that pattern on a fake cache folder with two app folders and a .DS_Store file (my scratch path is shortened to ~/scratch below):
rm -rf ~/scratch/FakeCaches/*
ls -A ~/scratch/FakeCaches
.DS_Store
Two surprises. First, the * glob skips hidden files, so it never fully empties the folder. Second, running it again on the now “empty” folder failed in zsh:
zsh:1: no matches found: ~/scratch/FakeCaches/*
The bigger problem is what you cannot see. Wiping everything can sign you out of some apps, can delete data that an app chose to keep in its cache folder, and throws away caches that make apps start fast. Apps then rebuild them, so the space often comes back within days.
If you really want to empty a folder you own, this form removes hidden files too and keeps the folder itself:
find ~/scratch/FakeCaches -mindepth 1 -delete
That emptied my fake folder completely, including the folder with a space in its name. Point it at one app’s cache folder, not the whole ~/Library/Caches.
Other “caches” people mean
- DNS cache: needs
sudo. See how to flush DNS on Mac. - RAM: macOS uses free memory as file cache on purpose. Clearing it does not speed things up. See how to check RAM usage in Terminal.
- Big files that are not cache: old downloads and disk images often take more space than any cache.
Common questions
Is it safe to delete everything in ~/Library/Caches?
Mostly, but it is not smart. Apps rebuild their caches, so you gain space only for a while, and some apps lose state. Delete the top few folders instead, with the app closed.
How do I clear cache on Mac with Terminal?
Find the big folders with du -sh ~/Library/Caches/* | sort -h, quit the app, and delete its folder with rm -rf. For Homebrew, npm and pip, use brew cleanup --prune=all, npm cache clean --force and pip3 cache purge.
Why does du say “Operation not permitted”?
Those folders are protected by macOS privacy rules (for example Safari and Find My caches). Terminal needs Full Disk Access to read them. You do not need to delete them.
Does clearing cache make a Mac faster?
Usually not. It frees disk space. Apps may even feel slower for a while because they have to rebuild the cache.
Where is the system cache on a Mac?
/Library/Caches (small on my Mac, 7.1 MB) and the per-user folder from getconf DARWIN_USER_CACHE_DIR under /var/folders. Leave both to macOS.