How to clear cache on a Mac safely — and what never to touch

The three cache locations, and who owns them

macOS has three cache directories and they are not equally safe.

~/Library/Caches is per-user and holds caches written by apps you run. This is the one people mean, and the great majority of it is regenerable. /Library/Caches is system-wide and holds caches written by installers and background services; it is smaller and slightly riskier. /System/Library/Caches belongs to the operating system, is protected by System Integrity Protection, and must be left alone — you will usually be refused permission anyway, which is the correct outcome.

Inside ~/Library/Caches each app gets a folder named by its bundle identifier: com.google.Chrome, com.apple.Safari, com.spotify.client, com.tinyspeck.slackmacgap. Ranking them tells you immediately whether it is worth doing anything at all.

du -h -d 1 ~/Library/Caches 2>/dev/null | sort -rh | head -20

The rule that makes this safe

A cache is, by definition, data that can be recreated from a source of truth. The risk is never that the data is irreplaceable; it is that the app is running while you remove the file it is mid-write to, which can leave it in a confused state until relaunch.

So the procedure is: quit the app, move its cache folder to the Trash, relaunch the app, use it normally for a day, then empty the Trash. That sequence makes every step reversible until the last one. Deleting the folder for an app you are not running is close to risk-free.

• Quit the app first. Always.
• Move to Trash; do not use rm. The Trash is your undo.
• Delete the contents of a cache folder rather than the folder itself when an app is fussy about its own directory existing.
• Expect the first launch afterwards to be slower — that is the cache rebuilding, and it is the cost you accepted.

Caches worth clearing

These reliably hold real space and rebuild cleanly:

• Browsers — ~/Library/Caches/com.google.Chrome, .../com.apple.Safari, .../com.brave.Browser, .../com.microsoft.edgemac, and ~/Library/Application Support/Firefox/Profiles/*/cache2. Commonly 1–5 GB each. Clearing them logs you out of nothing; cookies and sessions live elsewhere.
• Xcode — ~/Library/Developer/Xcode/DerivedData and ~/Library/Caches/com.apple.dt.Xcode. Often the largest single item on a developer Mac.
• Package managers — ~/Library/Caches/pnpm, ~/.npm/_cacache, ~/Library/Caches/Yarn, ~/.cargo/registry/cache, ~/Library/Caches/pip, ~/Library/Caches/Homebrew, ~/Library/Caches/go-build, ~/Library/Caches/ms-playwright. Each has a proper command to clear it (npm cache clean --force, pnpm store prune, brew cleanup, go clean -modcache, cargo cache, which needs the third-party cargo-cache subcommand) which is preferable to deleting the directory.
• Communication and design apps — Slack, Discord, Notion, Figma and Adobe apps all cache assets indefinitely and rebuild them on demand.
• Spotify and other media apps — ~/Library/Caches/com.spotify.client stores offline audio; clearing it means re-downloading anything you had saved for offline listening.

brew cleanup --prune=all
npm cache clean --force
pnpm store prune
go clean -modcache

What never to touch

Some directories sit near the caches and look like caches, and are not.

• ~/Library/Keychains — your passwords and certificates. Deleting this is unrecoverable.
• ~/Library/Application Support — real app data. Some apps do put caches here, but so is your Notes database, your Signal message history and your app licences. Only touch a specific subfolder you can name.
• ~/Library/Containers — sandboxed apps store your documents here, not just caches.
• ~/Library/Mail — deleting it can lose locally-stored messages for accounts that are not fully synced.
• ~/Library/Preferences — app settings. Deleting resets apps; it does not free meaningful space.
• /System, /usr (other than /usr/local), /bin, /sbin, /private/var/db — operating system. Nothing here is yours to remove.
• Anything inside a .photoslibrary, .musiclibrary or .app bundle — these are packages containing databases, not folders of loose files.

If you cannot say what an app would lose by having a folder deleted, that is the signal to leave it alone. The space you would save is rarely worth the afternoon.

Browser caches, in a little more detail

Browsers deserve their own paragraph because they are usually the largest cache on a non-developer Mac and because the terminology confuses people.

A browser keeps at least four separate stores, and only one of them is the cache. The HTTP cache holds copies of images, scripts and stylesheets so pages load faster; deleting it costs you nothing but a slower first reload. Cookies and session storage keep you signed in and live elsewhere. Site data — IndexedDB and local storage — holds things like offline documents in web apps, and deleting it can genuinely lose unsynced work. Profile data holds bookmarks, history and saved passwords, and must never be touched.

Clearing the cache from inside the browser (Chrome: Settings → Privacy → Delete browsing data, with only "Cached images and files" ticked) is safer than deleting the directory, because the browser then updates its own index rather than discovering a missing file later. Deleting ~/Library/Caches/com.google.Chrome while Chrome is closed is also fine and slightly more thorough.

One caveat that catches people out: Chrome and its relatives keep a separate cache per profile. If you use work and personal profiles, both need clearing, and the sizes are reported separately.

How much this is actually worth

Be realistic about the payoff. On a typical non-developer Mac, clearing every user cache returns 5–15 GB, and roughly half of it comes back within a week as the apps refill. It is worth doing once when you are short of space; it is not a maintenance ritual, and it is not the reason your Mac feels slow.

On a developer Mac the numbers are different — DerivedData and simulator runtimes alone are frequently 40 GB or more — but those are covered by their own articles because the safe procedures are specific to Xcode.

If you want the ranked answer without running commands, Dropit groups caches per app with their real sizes and marks each one with why it is safe: "regenerable cache — Chrome rebuilds it on next launch" reads differently from "app data". Seeing the list is free. Sending the selection to the Trash in one action is the paid part, and it uses the real Trash, so Put Back works.