'Not Enough Disk Space' on Mac: What to Delete First

This is the version of this problem where you don’t have time to read a long explainer — something is blocked right now and you need space back in the next five minutes. Here’s the order that actually works, fastest and highest-yield first.

First, see how bad it is

df -h /

The Avail column is what you have to work with. macOS itself gets uncomfortable below roughly 10% free on the whole volume — if you’re near that line, the steps below in order should get you clear of it quickly.

Step 1: Empty the Trash properly

The single most common reason “I deleted stuff but I still have no space” — deleting a file moves it to the Trash, which still counts against your used space until the Trash is actually emptied:

# Empty Trash from the shell, including large files that macOS's own
# "Empty Trash" sometimes prompts extra confirmation for
rm -rf ~/.Trash/*

If you deleted a large file specifically to free space and didn’t empty the Trash afterward, this step alone often solves the whole problem.

Step 2: Downloads folder, sorted by size

The second most common offender — installers, .dmg files, and large downloads people forget about entirely once they’ve used them once:

du -sh ~/Downloads/* 2>/dev/null | sort -hr | head -20

.dmg and .pkg installer files are the classic culprit here — you install the app, the disk image sits there forever afterward, fully redundant with the app now installed. Safe to delete any installer for software you’ve already set up.

Step 3: Local Time Machine snapshots

If you have a laptop, macOS very likely has hourly local snapshots consuming space you don’t know about — this can be 10–40 GB you get back in under a minute:

tmutil thinlocalsnapshots / 10000000000 4

See the full explanation of what this does and when it’s safe if you want the detail — the short version is: safe unless local snapshots are your only backup, which for most people they aren’t.

Step 4: ~/Library/Caches, blanket

If steps 1–3 didn’t get you clear, this is the next highest-yield, lowest-risk move — Apple’s own designated location for exactly this kind of disposable data:

rm -rf ~/Library/Caches/*

Full explanation of why this is safe, and the small number of exceptions worth knowing about, is in the dedicated guide to this folder — but for an emergency, this command is safe to run without reading further first.

Step 5: If you’re a developer, the big three

These three alone commonly account for 50–150 GB combined on a machine that’s done any amount of iOS, Docker, or Node development:

rm -rf ~/Library/Developer/Xcode/DerivedData/*
docker system prune -a --volumes    # only if you have Docker installed and running
find ~ -name "node_modules" -type d -prune -exec du -sh {} \; 2>/dev/null | sort -hr | head -10

Each has a dedicated guide with the full detail: DerivedData, Docker, node_modules.

If none of that was enough

At this point the remaining space is almost certainly in either your actual files — Photos library, Music, Documents — which this article deliberately doesn’t touch, since that’s your data, not cache, and you should decide what to do with it deliberately rather than under time pressure. Or it’s in “System Data,” Apple’s catch-all bucket covered in a separate guide, which requires more investigation than an emergency five-minute pass can cover.

Why this keeps happening

None of the five steps above are one-time fixes — every one of them refills. Caches regenerate as you use apps, DerivedData refills the moment you build, Time Machine snapshots resume hourly the moment you delete them. The emergency fix and the actual fix are different things: this article gets you unblocked today; the actual fix is keeping an eye on the same five categories before any of them reaches “blocking an export” severity.

That is what DevCruft, a free Mac app for developers we’re building, is being designed to do continuously. Join the waitlist if you want to hear when it’s ready.