macOS pops the "Your disk is almost full" warning. You open Finder,
and the volume still says 40 GB available. You empty the trash,
delete a few big files, and the number barely moves. Nothing here is
broken. The Mac is telling the truth and so is Finder; they're just
answering two different questions. Here's how to see what's actually
holding your space and get it back.
01 Two numbers that disagree
The fastest way to see the gap is in Terminal. Run df -h /
and you'll get the filesystem's own view: total size, used, and
available. Then look at Finder's Get Info on the same volume, or open
About This Mac and click the storage breakdown. The two will
often disagree by tens of gigabytes.
Neither is lying. df reports what the filesystem has
committed right now. Finder reports what you could write if you
tried, which includes space macOS is willing to reclaim on demand.
That reclaimable space has a name, and it's the first thing to
understand.
02 Purgeable space
On APFS, macOS keeps a category of data it calls purgeable:
caches, downloaded-again-anytime files, old snapshots, and anything
the system has decided it can delete the moment you need the room.
Finder counts purgeable space as available, because from your
perspective it effectively is. The catch is that it stays on disk
until something forces the cleanup, so the "almost full" warning and
the "space available" number are both correct at the same time.
You can see it directly. Open About This Mac, go to the
storage view, and hover the segments; the system labels one of them
Purgeable. If that number is large, the space isn't
lost, it's parked. The usual reason it got large is the next section.
03 Local Time Machine snapshots
This is the culprit on most Macs. Time Machine doesn't only write to
your external backup drive. Several times a day it takes a
local snapshot, a frozen point-in-time copy of the volume,
and stores it on the same internal disk. Snapshots are cheap when
they're new because APFS shares the unchanged blocks, but as files
change, the snapshot has to hold onto the old versions, and a few
days of them can quietly occupy 20, 50, even 100 GB.
macOS marks these as purgeable and thins them automatically when it
needs room, which is why the space looks available. If you want it
back now rather than whenever the system decides, you can list and
remove them yourself. In Terminal:
See them:tmutil listlocalsnapshots /
prints every local snapshot on the startup volume, named by
timestamp.
Thin them:tmutil thinlocalsnapshots / 50000000000 4 asks macOS
to free roughly 50 GB by removing the oldest snapshots, at the
most aggressive urgency level.
Remove one:tmutil deletelocalsnapshots 2026-06-07-160539 deletes
a single snapshot by its timestamp.
Turning Time Machine off and on again, or excluding a churning folder
from backups, will slow the rate they pile up. They are not a bug, and
you do generally want some of them, since they're what powers
"enter Time Machine" recovery when your backup drive isn't connected.
But they're the answer to "where did 60 GB go" far more often than
anything in your home folder.
04 The APFS counting trap
Even once purgeable space and snapshots are accounted for, the numbers
can still feel wrong, because on APFS the "size" of a file and the
bytes it costs you are two different things. Duplicated files, Xcode
support folders, and anything copied with clone-on-write share storage
under the hood. Finder's Get Info and most disk tools report the
logical size, the sum of file lengths, which can be many times
the space those files actually occupy.
This is why a folder Finder swears is 87 GB can free only
12 GB when you delete it. If you want the full version of this
story, with the syscalls and the dedup logic, we wrote it up in
Counting bytes on APFS. The
short version: to know what a folder will actually give you back, you
need a tool that counts on-disk, deduplicated bytes, not logical ones.
05 The quick wins, in order
Before reaching for anything fancier, clear the things that hold space
without showing up where you'd look:
Empty the Trash, including per-app trash. Photos,
Mail, and many apps keep their own "recently deleted" bin that the
Finder trash doesn't touch.
Check Downloads and the Desktop. Disk images,
installers, and old exports accumulate here and are almost always
safe to remove.
Clear developer caches if you have them.~/Library/Developer/Xcode/DerivedData and old
simulator runtimes are among the largest reclaimable folders on a
developer's Mac, and they rebuild themselves on demand.
Restart. A reboot forces macOS to run the cleanup
it had been deferring, so purgeable space often drops on its own
afterward.
06 Finding what actually costs you
Once the easy wins are gone and the disk is still tight, the question
becomes "which folders are genuinely large," and this is exactly where
Finder and most tools send you on a wild goose chase by showing logical
sizes. You want a visual map of the disk that ranks folders by the
bytes they really occupy.
That's the tool we built. Delve scans your disk
and draws every folder as a rectangle sized by its real on-disk
footprint, with clones and hardlinks deduplicated and iCloud
placeholder files marked so a 4 GB stub doesn't pretend to be
4 GB of local storage. The big rectangles are the folders worth
your attention, and the number Delve shows is the number you'll
actually get back when you delete them. It's free, native, and never
sends your filesystem anywhere.
Your disk isn't broken and your Mac isn't lying. The "full" warning
counts what's committed right now; the "available" number counts what
macOS can reclaim. The gap between them is almost always purgeable
space, and most of that is local Time Machine snapshots. Thin the
snapshots, clear the obvious caches, restart to force the cleanup, and
then use an honest disk map to find whatever real, unique data is left.
The space was there the whole time. It just wasn't where the menu bar
pointed.