How to clear caches on your Mac without breaking anything

Somewhere between the advice that says clearing caches fixes everything and the horror stories about broken apps sits the boring truth: cache contents are safe to delete, cache folders are not, and the best way to clear a cache is usually the one the app or tool provides itself. This guide covers where caches live on a Mac, which ones are worth clearing, the right method for each, and the cases where clearing a cache will not fix what you are actually trying to fix.

What a cache is, and why apps hoard them

A cache is a copy of something the app can get again: a thumbnail it rendered, an image it downloaded, a compiled file it built. Apps keep caches because recomputing or re-downloading is slow, and disk space is cheap until it is not. Nothing original lives in a cache; by definition it is reproducible.

That is why deleting cache contents is safe in principle. The cost is never lost data; it is the time for the app to rebuild what it needs, a slower first launch, pictures loading over the network again, a longer next build. The risk stories come from a different mistake: deleting the wrong thing alongside the cache, or deleting a folder an app expected to exist.

The three places caches live on a Mac

Nearly every cache on your Mac sits in one of three locations. Your user cache folder, ~/Library/Caches, holds a subfolder per app, this is where Spotify, browsers, and most Mac apps keep theirs, and it is usually the largest. The system-wide /Library/Caches holds shared caches and is best left to macOS. And ~/.cache, a hidden folder in your home directory, is where command-line and cross-platform tools follow the Unix convention: pip, Hugging Face, linters, and dozens of others.

Sandboxed apps complicate the picture slightly: their caches live inside ~/Library/Containers under each app's container, and Electron apps like Slack and Discord keep multi-gigabyte caches inside ~/Library/Application Support next to real user data. That last location is exactly why blanket deleting is a bad habit; in Application Support, cache and data sit side by side.

To see which apps are hoarding, size your user cache folder and sort it:

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

The one rule: delete contents, not folders

When you do clear a cache by hand, open the app's cache folder and delete what is inside it, then leave the folder standing. Some apps recreate a missing folder without complaint; others error, behave oddly, or rebuild permissions in surprising ways. Keeping the folder costs you nothing and removes the whole class of problem.

Quit the app first. An app that is running holds locks and indexes over its cache, and deleting files out from under it is how you get the corrupted-cache weirdness the horror stories describe. Quit, delete the contents, relaunch. And use the Trash rather than any permanent delete, so the one time a folder turns out to matter, you can put it back.

Per-app notes: browsers, Spotify, Slack, Xcode

Browsers prefer to clear their own caches. Safari does it from Settings, Privacy, Manage Website Data, or the Develop menu's Empty Caches if you have enabled that menu; Chrome and Firefox from their Clear Browsing Data screens, where you can clear cached files without touching passwords or history. Deleting browser profile folders in the Finder is the wrong tool; profiles mix cache with logins and bookmarks.

Spotify's cache of streamed music can quietly reach many gigabytes; the app has its own control under Settings, Storage, and respects a size limit there. Slack and Discord rebuild their caches on next launch, and both are notorious for hoarding; Slack offers Clear Cache in its Help menu, and both tolerate having their Cache subfolders emptied while quit.

Xcode is its own world: DerivedData, module caches, simulator caches, and a download cache, each safe to clear and each rebuilt at the cost of a longer next build. If a project misbehaves after an Xcode update, clearing DerivedData is the standard first move, and it lives in ~/Library/Developer/Xcode.

Official cleanup commands beat manual deleting

Command-line tools almost always ship a cache command, and it is strictly better than deleting their folders. npm cache clean --force, brew cleanup, docker system prune, pip cache purge, cargo's cache subcommands: each knows its own layout, respects its locks, and updates its indexes so the tool is not confused afterward. Manual deletion of the same folders works most of the time; the official command works every time.

The same principle scales up to system-managed data. Time Machine local snapshots are cleared through tmutil, not by hunting for files. Where an official path exists, use it. This is, incidentally, the model Diskmack follows when it cleans: official command where one exists, move to Trash where one does not, and never a raw delete.

When clearing caches will not fix it

Clearing caches is the right move for exactly two problems: a specific app misbehaving in a way that smells like stale data, and cache folders that have grown genuinely large. It does not make a slow Mac fast; caches exist to make things faster, and clearing them makes the next launch slower. It is a poor way to free space durably, because active caches regrow within days to their working size.

If your real problem is a full disk, caches are usually a minority of it. The durable space on a full Mac hides in old iPhone backups, Docker images, developer build products, media libraries, and forgotten downloads. Clear the two or three genuinely oversized caches, then go after those instead; the linked pages below cover each one, and a disk map app like Diskmack shows in one screen which category your missing gigabytes are actually in.

Common questions

Is it safe to delete everything in ~/Library/Caches?

Mostly, but it is a blunt instrument. Every app rebuilds its cache, so nothing is lost permanently, but you sign yourself up for slow first launches everywhere, and a few badly written apps behave oddly until their folder structure is rebuilt. Clearing the two or three largest app folders inside it gets nearly all the space with none of the churn.

Why did my cache come back after I cleared it?

Because that is what caches do. An active app rebuilds its working cache within days; Spotify re-downloads the music you stream, a browser re-saves the sites you visit. Clearing caches buys temporary space. If a cache regrows past a size you like, look for the app's own cache size setting, or accept that the app genuinely uses that much.

Will clearing caches speed up my Mac?

Generally no, and often the opposite for a few days. Caches exist to avoid repeated work; a cleared cache means the work happens again. The exception is a corrupted cache making one specific app misbehave, where clearing that app's cache is a legitimate fix. For overall slowness, look at memory pressure and login items instead.

Do I need a third-party app to clear caches?

No, everything in this guide works with Finder and Terminal. A tool earns its place by telling you what each folder is before you delete it and by using safe methods automatically. That identification step is the part people actually get wrong by hand, and it is the part Diskmack automates with a rules database covering the folders that matter.