~/Library/Caches: The One Folder Behind Half of This Blog

If you’ve read more than one article on this blog, you’ve noticed a pattern: DerivedData, browser caches, Electron app caches, CocoaPods, JetBrains indexes — an enormous share of them live somewhere under one single directory. It’s worth looking at that directory directly, once, rather than per-app.

open ~/Library/Caches

Finder hides ~/Library by default — hold Option while clicking the Go menu in Finder to reveal it, or use the open command above, which bypasses the hidden-folder setting entirely.

Why this folder exists and why it’s safe by design

~/Library/Caches is Apple’s own designated location for exactly this purpose — data any app can regenerate or re-download, that the operating system is explicitly allowed to purge under disk pressure. It’s not a convention developers invented; it’s a documented part of Apple’s file system layout, and every well-behaved Mac app is supposed to use it for anything non-essential.

That single fact is what makes this folder unusually safe to clear broadly, compared to almost anywhere else on your disk: by Apple’s own design, nothing here is supposed to be the only copy of anything that matters. The practical exceptions — a handful of apps that misuse the Caches folder for data that isn’t really disposable — are rare enough to be worth naming specifically, which this article does below.

Reading it directly, ranked by size

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -30

On almost any Mac that’s been used for more than a year, this single command surfaces the exact same names covered across this blog’s other guides: com.apple.Safari, Google/Chrome, org.swift.swiftpm, Homebrew, CocoaPods, pip, JetBrains, plus dozens of smaller entries from apps you’d never think to check individually.

The folder names are almost always reverse-DNS bundle identifiers (com.company.AppName) or plain package names (pip, Homebrew) — if you see one you don’t recognize, mdfind "kMDItemCFBundleIdentifier == '<the-name>'" will usually tell you which installed app it belongs to.

The blanket-safe approach

For most people, most of the time, this is genuinely fine:

rm -rf ~/Library/Caches/*

Every well-behaved app rebuilds what it needs from this folder the next time it runs — that’s the entire point of the directory existing. The visible cost is the sum of every individual cost covered elsewhere on this blog: browsers re-fetch resources, package managers re-download on next install, Xcode’s index rebuilds, and so on — nothing breaks, several things are briefly slower.

The exceptions worth knowing by name

A small number of apps use their Caches subfolder for data that’s more expensive to lose than the word “cache” implies, covered in more detail in their own articles:

• Slack’s IndexedDB can hold unsent draft messages — see the Slack and Discord guide.
• Any app’s IndexedDB used as local-first storage (some PWAs, some note-taking apps) — see the browser cache guide.
• Docker’s cache technically lives outside this folder entirely — it’s inside a VM disk image under ~/Library/Containers, not ~/Library/Caches, which is worth knowing so a blanket clear of Caches doesn’t create a false sense of having addressed Docker too. See the Docker disk space guide.

Everything else covered across this blog — DerivedData technically lives under ~/Library/Developer, not ~/Library/Caches, another folder worth knowing sits just outside this one’s blast radius — is either directly inside ~/Library/Caches or governed by the same “safe to regenerate” principle even when Apple filed it under a slightly different top-level directory.

Why a scan beats a blanket delete anyway

rm -rf ~/Library/Caches/* is safe, but it’s also blind — it can’t tell you which three apps are responsible for 40 of the 45 GB in there, and it can’t warn you about the Slack IndexedDB exception above before it happens. A byte-for-byte breakdown, sorted and named, turns “clear the cache folder and hope” into “here are the four things actually worth knowing about, in order.”

DevCruft, a free Mac app for developers that’s still in development, is being built to read exactly this folder — plus DerivedData, Docker’s container storage, and everything else that lives just outside it — and give you the same ranked breakdown the du command above produces, with each entry labeled by what it actually is and whether it’s safe rather than a bundle identifier you have to look up by hand. Join the waitlist to hear when it’s ready.

This is the last of ten guides added in this round. For the original, broader tour of everything that fills up a developer’s Mac, start with the complete developer storage guide.