How to Clear Temp Files on Mac Safely
Your Mac did not “mysteriously” eat 40 GB. Temp files, caches, local snapshots, and leftover build junk did. Storage Settings will call most of that “System Data,” then shrug.
I have cleaned this mess on daily-driver MacBooks, M-series minis, and a few overstuffed developer machines. The same pattern shows up every time: browsers and IDEs quietly hoard gigabytes, Time Machine local snapshots sit in purgeable space, and one bad cleaner app promises magic while deleting the wrong folder.
This is the method I actually use. No mystery “one-click optimizer.” No touching `/System`.
What temp files on a Mac really are
macOS treats a lot of disposable data as first-class citizens. Apps write caches so the next launch feels instant. Compilers dump object files so the next build is faster. Browsers keep site assets. The system keeps logs, crash reports, and per-user scratch space under `/private/var`.
That design is smart until the disk fills. Then Spotlight crawls slower, Time Machine gets cranky, and thermal throttling shows up on machines that used to stay cool. Full disks and dirty internals often travel together; the same users who never clean a computer safely also never empty caches.
Temp data is not one folder. It is a stack:
- User app caches in `~/Library/Caches`
- System-wide caches in `/Library/Caches`
- Browser site data and service workers
- Logs in `~/Library/Logs` and `/private/var/log`
- Per-user scratch under `/private/var/folders`
- Time Machine local snapshots (APFS)
- Developer artifacts: Xcode DerivedData, Homebrew downloads, npm/pip/Docker layers
- Purgeable space macOS can reclaim when it feels like it
Caches are meant to rebuild. Personal files, Keychain items, and most app settings are not caches. Mix those two and you get the horror stories.
Where the space actually hides
Open Storage in System Settings and you will see Photos, Apps, and a bloated “System Data” slab. That slab is the unhelpful bucket. The useful map is the filesystem.
Typical safe recoveries on a 256–512 GB machine, from machines I have measured:
- `~/Library/Caches`: 2–12 GB
- Browser caches and service workers: 1–6 GB
- Xcode DerivedData + simulators: 10–60 GB on active iOS projects
- Homebrew cache: 1–8 GB
- Docker images and build cache: 5–40 GB
- Local Time Machine snapshots: anywhere from a few GB to half the disk
- iPhone Mirroring / iCloud Drive caches on recent macOS: several GB if you use those features
`/tmp` itself is usually small. The scary number is almost never `/tmp`. It is Library plus developer folders plus snapshots.
Do not start inside `/private/var/folders` with Finder and a hopeful delete key. That tree holds per-user temporary items and running-process state. macOS hides it for a reason.
Method comparison before you touch anything
Pick a lane. Mixing a reckless Terminal wipe with a third-party cleaner is how people break login items.
| Method | Best for | Setup effort | Space you usually get | Risk | Value |
|---|---|---|---|---|---|
| System Settings → Storage | Casual users, first pass | Low | Modest; good at Large Files and old iOS backups | Low | High for beginners |
| Finder on `~/Library/Caches` | Targeted app junk | Low | 2–10 GB | Low if you delete contents only | High |
| Browser settings | Web cache only | Low | 1–5 GB | Low | High |
| Terminal (`rm`, `du`, `tmutil`) | Power users, repeatable cleanup | Medium | Large, if you know the paths | High if you type the wrong path | High |
| Third-party cleaners | People who refuse Terminal | Low | Variable; often oversells | Medium–high | Mixed |
| Developer-specific tools (`brew cleanup`, `xcrun simctl`, Docker prune) | Coders | Medium | Often the biggest win | Medium if you prune live images | Very high |
If you only do one thing today, use Storage Settings plus `~/Library/Caches`. If you compile code for a living, the developer tools beat any generic “Mac cleaner.”
First pass: built-in Storage tools
Quit heavy apps. Slack, Chrome, Docker, Xcode, and Adobe suites keep files open. Deleting a cache while the app is writing to it is how you get a half-broken preference file.
Then:
1. Open System Settings → General → Storage.
2. Wait for the categories to finish calculating. That spinner is slow on full disks.
3. Review Applications. Delete installers and apps you have not launched in a year.
4. Open Documents and sort by size. Downloads is usually a landfill.
5. Check iOS Files / iPhone backups if you sync devices.
6. Empty Trash. Storage numbers lie until Trash is gone.
Optimize Mac Storage can offload iCloud content you have not opened lately. That is not the same as deleting temp files. It just moves your stuff to Apple’s servers. Use it only if you actually live in iCloud.
Restart after a big cleanup. A reboot lets `deleted` and APFS reclaim purgeable blocks that Finder still counted as used.
Clear user caches in Finder without wrecking apps
This is the safest manual win.
1. Quit the apps whose caches you plan to wipe.
2. In Finder, press Shift-Command-G.
3. Go to `~/Library/Caches`.
4. Sort by size if you can; otherwise hunt the obvious names: Google, Chrome, Slack, Spotify, Docker, Adobe, Zoom.
5. Open a cache folder. Select the contents. Move those to Trash.
6. Leave the folder itself in place. Many apps expect the directory to exist.
7. Repeat for `/Library/Caches` only if you know what you are deleting. Skip anything that looks like an Apple system service if you are not sure.
8. Empty Trash. Restart.
Never delete `/System/Library/Caches`. You do not need that space. You do need a Mac that boots.
Safari cache is cleaner from Safari itself: Settings → Advanced → show the Develop menu, then Develop → Empty Caches. Chrome users should use `chrome://settings/clearBrowserData` and tick cached images only unless they also want cookies gone.
Pro Tip: Delete the *contents* of a cache folder, not the folder name. I have watched apps recreate a missing directory with broken permissions, then spend the next week complaining they cannot write a thumbnail store.
Terminal workflow I use on stubborn machines
Finder is fine until you want numbers. Terminal tells you which folder is the pig.
Check size first:
```bash
du -sh ~/Library/Caches
du -sh ~/Library/Logs
du -sh ~/Library/Developer/Xcode/DerivedData
brew --cache
```
Clear user caches after quitting apps:
```bash
rm -rf ~/Library/Caches/*
```
Clear logs you do not need:
```bash
rm -rf ~/Library/Logs/*
```
Xcode build junk:
```bash
rm -rf ~/Library/Developer/Xcode/DerivedData/*
xcrun simctl delete unavailable
```
Homebrew leftovers:
```bash
brew cleanup -s
```
Local Time Machine snapshots:
```bash
tmutil listlocalsnapshots /
```
Then delete a dated snapshot with `tmutil deletelocalsnapshots` and the date stamp it printed. Do not invent dates.
I do not recommend a blind `sudo rm -rf /Library/Caches/*` on a machine you cannot reinstall this afternoon. It is usually safe. “Usually” is a terrible word next to `sudo rm -rf`.
DNS cache is memory-only and tiny, but it is a useful reset when lookups go weird:
```bash
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
```
That will not free 20 GB. It will stop you blaming “temp files” for a stale DNS record.
Developer and power-user sinks
This is where “System Data” becomes a joke. A single Xcode project with three simulator runtimes can dwarf every Safari cache you have ever grown.
Safe, high-yield targets:
- `~/Library/Developer/Xcode/DerivedData`
- Old iOS DeviceSupport folders you no longer flash
- Unavailable simulators via `xcrun simctl delete unavailable`
- `~/.npm` and Yarn caches
- pip / uv / conda package caches
- Docker: unused images, build cache, stopped containers
- Android SDK emulator AVDs you abandoned
- Gradle caches on dual-stack setups
Caution pile:
- Xcode Archives you might still need to symbolicate a crash
- Docker images you have not tagged but still run weekly
- `~/Library/Application Support` in general. That folder is not a cache dump. Slack, VS Code, and games keep real state there.
Danger pile:
- Random deletion inside `/private/var/folders`
- Anything under `/System`
- Wiping all of `~/Library/Developer` because it “looked technical”
If RAM pressure and swap files are the real complaint, cleanup helps only at the edges. You still need a honest look at [how much RAM you need](https://www.artificialignorance.net/2026/08/how-much-ram-do-you-need.html) for Chrome-plus-IDE-plus-Docker. A 8 GB machine with three Electron apps will swap no matter how empty `~/Library/Caches` is.
Docker users should prefer `docker system prune` over Finder. Deleting overlay folders by hand is how you corrupt the engine and then spend an evening reinstalling it.
Third-party cleaners, and why I rarely trust the big button
CleanMyMac, OnyX, DaisyDisk, and the latest App Store “cleaner” all do something. DaisyDisk is useful because it visualizes size. OnyX is useful if you already understand what a maintenance script does. One-click “Free 42 GB” buttons are marketing.
Problems I keep seeing:
- They count purgeable space as a victory, then the number comes back tomorrow.
- They offer to delete browser data you still wanted.
- They request Full Disk Access and then sit in the background forever.
- They fight SIP and leave you with half-applied “optimizations.”
If you want a visual map, use DaisyDisk or GrandPerspective, then delete the folders yourself. If you want automation, write a small shell script you can read. An opaque slider is not a backup strategy.
Honest limitations
Clearing temp files is not a new SSD. It is not a thermal paste job. It will not fix a failing NAND chip.
What cleanup will not do:
- Recover space Apple still marks as snapshots until you delete or wait them out
- Make a 256 GB machine comfortable if your Photos library and Steam library both live locally
- Repair a corrupted user Library after a cleaner already ran
- Stop apps from rebuilding caches the next afternoon
Side effects you should expect:
- First launch after a cache wipe feels slower
- Some apps sign you out of web views
- Xcode reindexes
- Homebrew redownloads bottles you just deleted
- Font caches rebuild and, rarely, a font looks wrong until you reboot
If the Mac is already cooking under load, empty space helps airflow and swap less than people think. Dust in the intake and a packed SSD can stack. That is a hardware problem as much as a files problem, closer to classic PC overheating causes than to a cache tutorial.
APFS snapshots confuse everyone. Storage Settings may show used space that `du` does not see. The system can purge that data when it wants more room. Forcing the issue with `tmutil` is valid. Panic-deleting `/private/var` is not.
Pro Tip: If Storage Settings and Finder disagree by tens of gigabytes, list local snapshots before you delete anything else. I have “found” 80 GB that was just Time Machine holding a local copy after a fat Time Machine run.
A repeatable monthly routine
This is the schedule that keeps my own machines from hitting the 20 GB warning.
Weekly, if you ship code:
- Quit Docker and run `docker system prune` when images pile up
- Dump DerivedData if builds feel haunted
- Empty Trash
Monthly:
- Check `du -sh ~/Library/Caches`
- Clear the two or three fattest app caches
- `brew cleanup -s`
- Review Downloads and old disk images
- Empty browser caches if you test web apps all day
Quarterly:
- Review simulators and old DeviceSupport
- Delete dated local snapshots you do not need
- Look at `~/Library/Logs`
- Reboot and re-check Storage
Keep SIP on. Keep Time Machine or another versioned backup on a separate volume. A cache wipe is reversible. A bad `rm` in the wrong home folder is not.
Show hidden files only when you need them. Command-Shift-Period in Finder is enough. Leaving invisible files visible all day just invites curiosity deletions.
Pro Tip: On recent macOS builds, iPhone Mirroring and Apple Intelligence can grow their own cache trees under Group Containers. If Storage still looks obese after a normal Library sweep, check those feature folders before you assume the disk is dying.
FAQ
Is it safe to delete everything in ~/Library/Caches?
Yes, if apps are quit and you delete contents rather than random parent folders higher up. Apps rebuild caches. You may get slower first launches and a few re-logins. You will not delete your documents.
Why does System Data stay huge after I empty caches?
Snapshots, local Time Machine copies, iOS backups, sleep images, and developer runtimes hide in that bucket. `du` on Library will not show APFS snapshot usage. List snapshots. Check iPhone backups. Check Docker and Xcode.
Should I delete /private/var/folders to free space?
No as a first move. That tree is live scratch for user processes. If it is genuinely enormous and the Mac is idle, reboot first and let the system purge. If it stays absurd after a reboot and a snapshot cleanup, you have a stuck process or a third-party tool leaking files. Fix the process. Do not RM the tree.
Do I need a paid cleaner app?
No. Finder, Storage Settings, and a few Terminal commands cover the real wins. A visual disk map can help. A subscription that wants Full Disk Access to delete Safari cache is optional at best.
What I would do on your Mac tonight
Start with Storage Settings and Trash. Then wipe `~/Library/Caches` contents. Then measure the developer folders if you write software. Then look at snapshots.
That order avoids drama. It also matches how macOS actually stores disposable data, instead of how cleaner ads describe it.
Temp files will come back. That is the point of a cache. The skill is knowing which piles are cheap to burn and which folders are load-bearing. Do that once with your eyes open and you will stop treating “System Data” like a ghost.
Disks are still getting smaller in the base models Apple wants to sell. Cleanup literacy is not optional if you want those machines to last more than a year without a nervous Storage bar. Keep the script. Skip the magic button.
