How to Clear Cache on Mac Without Breaking Your Dev Setup

Here is how to clear cache on Mac: empty your browser cache first, then delete the contents of ~/Library/Caches, then flush the DNS cache if a site still misbehaves. That covers 90% of cases and takes about two minutes. If you write code, the real weight sits elsewhere: Xcode DerivedData, Homebrew downloads, npm and Docker layers. Those are covered below, with the commands.

What does clearing cache on a Mac actually free up?

A cache is data an app can rebuild. Delete it and the app re-downloads or recomputes it, so the first launch afterwards is slower. Nothing you created is lost. That is the whole contract, and it is why cache is the safe category to clean.

Here is the split that matters. Browser cache fixes stale pages and broken logins. The user cache in ~/Library/Caches frees disk space and clears odd app behavior. The DNS cache fixes "site not found" after a server move. Developer caches free the most space by far.

Measure before you delete. One command tells you where the weight is:

# size of every per-app cache folder, largest last
du -sh ~/Library/Caches/* 2>/dev/null | sort -h | tail -15

If the biggest folder is under 500 MB, you do not have a cache problem. Skip the rest of the disk-space sections and go straight to the browser or DNS fix you need.

How do you clear browser cache in Safari and Chrome?

Safari hides its cache control. Open Safari, go to Settings, then Advanced, and tick "Show features for web developers". A Develop menu appears. Choose Develop, then Empty Caches. The shortcut is ⌥ ⌘ E.

Do not confuse this with History, Clear History. Apple documents that one in its Safari history guide, and it removes history, icons and permissions, which is more than you wanted. Empty Caches only drops cached files.

Chrome is faster. Press ⇧ ⌘ ⌫, set the range to "All time", tick only "Cached images and files", and confirm. Leave cookies unticked unless you want to log in everywhere again.

Firefox works the same way: ⇧ ⌘ ⌫, then the cache box only.

Hard refresh is the cheaper test. ⇧ ⌘ R in Chrome and Firefox, ⌥ ⌘ R in Safari with the Develop menu on. If the page fixes itself on a hard refresh, you never needed to wipe anything.

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

Mostly yes, with one rule: delete the contents of each folder, not the folders themselves, and quit the app that owns the folder first. Some apps expect their cache directory to exist and fail to launch when it does not.

Open it from Finder with ⇧ ⌘ G, then paste ~/Library/Caches. Or from Terminal:

# quit apps first, then remove cache contents but keep the folders
find ~/Library/Caches -mindepth 2 -delete 2>/dev/null

Two things to skip. Leave /System/Library/Caches alone: it is protected by System Integrity Protection and you do not want to fight it. Leave /Library/Caches alone unless you know which vendor folder you are removing, because installers and drivers sometimes park receipts there.

Do you need to restart afterwards? Yes, once. Several system daemons hold file handles on their cache files, and a restart lets them rebuild cleanly. Expect the first login to feel slower. Spotlight may reindex for a few minutes.

One more caveat that nobody mentions: the number you free is smaller than the number you see. macOS already evicts its own caches when the disk fills up. If your goal is "more free space", clearing ~/Library/Caches buys less than deleting an old Xcode simulator.

Where do developer caches hide, and how big do they get?

This is where a Mac with two years of project work loses tens of gigabytes. None of it shows up in a "clear cache" guide written for general users. Each of these is rebuildable, so each is safe to remove.

Xcode DerivedData. Build products and indexes for every project you ever opened. Delete it when Xcode shows phantom errors or autocomplete dies.

# safe: Xcode rebuilds this on the next build
rm -rf ~/Library/Developer/Xcode/DerivedData/*

Homebrew. It keeps every downloaded bottle. brew cleanup -s removes old versions and scrubs the download cache, and brew --cache prints where the files live. The flags are documented in the Homebrew manual.

npm and pip. npm cache clean --force empties the npm cache, and pip cache purge does the same for pip. Both re-download on the next install.

Docker. Images, stopped containers and build cache pile up quietly. docker system prune removes stopped containers and dangling images. Add -a to drop every unused image, but only if you are fine with re-pulling them.

If you have more than one of these on your machine, run them in order of size. Check each with du -sh first, so you spend the re-download cost only where it pays back.

How do you flush the DNS cache on macOS?

Use this when a domain resolves to the old server after a migration, or when you edited /etc/hosts and nothing changed. Run both commands in Terminal:

# clear the resolver cache, then signal mDNSResponder to reload
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

No output means it worked. There is no confirmation dialog. The command works on current macOS releases, and it is the one fix on this page that needs an admin password.

Browsers keep their own DNS cache too. In Chrome, open chrome://net-internals/#dns and press Clear host cache. If a site still resolves wrong after both, the problem is upstream, at your router or your ISP resolver, and no local cleanup will fix it.

What about Mail, Photos and the "purge" command?

Mail keeps downloaded attachments and message bodies in ~/Library/Containers/com.apple.mail. That is not cache in the safe sense: delete it and Mail re-downloads from the server, which is fine for IMAP and a disaster for any account where mail only exists locally. Use Mail, Mailbox, Rebuild instead. It forces a clean re-sync without touching the container yourself.

Photos is the same story. The library holds your originals. Its thumbnail cache is rebuilt, but the folder layout inside the .photoslibrary package is not meant to be hand-edited. Leave it. If Photos feels slow, hold ⌥ ⌘ while launching it and run the repair option.

Then there is sudo purge. It does not clear files. It flushes the disk cache held in RAM, so the next file read hits the disk again. Developers use it to get honest cold-start timings when benchmarking an app, and for nothing else. Running it to "free memory" does nothing useful, because macOS already gives that memory back the moment a process asks for it.

# benchmarking only: forces the next read to come from disk
sudo purge

The Storage panel under System Settings, General, Storage is worth a glance too. It shows the size of "System Data" and "Developer", which is a faster way to find out whether Xcode is the culprit before you open Terminal at all.

Should you use a cleaner app or do it by hand?

Skip the all-in-one cleaner if you only want cache gone once or twice a year. The terminal commands above take two minutes and cost nothing. No subscription. No account. No background agent.

An app earns its place when you clean often and want a preview before deleting. Two things to check before you install anything: what it asks permission for (Full Disk Access is a big grant), and whether it phones home. A cleaner that runs a telemetry agent to tell you your disk is full has missed the point.

Native launchers also cover part of this job. They will not clean for you, but they cut the clicks. A launcher with a script runner turns the whole find plus brew cleanup routine into one hotkey. If you already run one, build the routine there instead of adding another app.

Alfred is the case in point. The Powerpack costs about $43 one-time, with no subscription, and its workflows can chain shell scripts, so a "clean my caches" keyword is a ten-minute build. If you have Alfred, this solves it. If not, skip.

Raycast takes the same approach with a free tier that includes clipboard history and window management. Its Pro plan runs $8 per month billed annually, so it is a subscription model. Fine for some stacks, not for those who want a one-shot price.

Setapp bundles 270+ Mac apps, cleanup utilities included, at $14.99 per month for one Mac. Do the math before you commit: a year of it costs more than most standalone cleaners. It makes sense only if you would use several of the bundled apps.

What are the mistakes that make cache clearing backfire?

Four, and they repeat. First, deleting while the app is running. The app recreates half the files mid-delete and you end up with a corrupt state. Quit it first.

Second, clearing everything weekly "to keep the Mac fast". Cache exists because rebuilding is expensive. If you wipe it every week, you pay the rebuild cost every week and gain nothing.

Third, treating cache as the cause of a slow Mac. A slow machine is usually memory pressure, a runaway process, or a full disk. Open Activity Monitor, sort by CPU, then by Memory, and look before you delete anything.

Fourth, removing Application Support or Containers because the names look similar. Those folders hold your settings, databases and documents for sandboxed apps. They are not cache. Anything that is not under a folder literally named Caches stays.

What is the routine we would actually run?

Once a quarter, run du -sh ~/Library/Caches/* | sort -h | tail, then brew cleanup -s, then clear DerivedData if you build in Xcode. Empty the browser cache only when a page breaks. Flush DNS only after a server move.

That routine takes five minutes and frees the space that matters. Do the rest on demand.