You delete twenty gigabytes, empty the Trash, and the free-space number barely moves. Or Finder claims you have 40 GB free while an installer insists there is not enough room. Both situations come from the same place: on APFS, "free space" is a negotiated number, not a measurement.
Purgeable space is not free space
APFS reports a figure that includes purgeable content: local Time Machine snapshots, cached iCloud files that exist on the server, and caches macOS believes it can regenerate. The system counts these as space it could reclaim under pressure, so Finder folds them into the number it shows you. They are not available to a process asking for a contiguous write right now, which is why an installer can fail on a disk that looks half empty.
You can see the split from the terminal:
diskutil info / | grep -E 'Free Space|Container'Compare that against what df reports, which ignores the optimistic accounting:
df -h /System/Volumes/DataA large gap between the two is normal on a machine with snapshots. A gap of tens of gigabytes usually means snapshots are the story.
Local snapshots are the usual culprit
Time Machine keeps local snapshots on the internal disk between backups, and keeps them even when no external backup drive has been connected for months. Each one pins the state of every file it references, so deleting a 30 GB video frees nothing until every snapshot referencing it expires.
tmutil listlocalsnapshots /macOS thins these automatically when the disk gets tight, which is why the space often reappears on its own an hour later. If you need it now, thinning is a documented operation, but deleting snapshots removes your ability to roll back to those points in time.
The other three places space hides
- iCloud Drive placeholders. Files marked "optimized" show their full size in some views while occupying almost nothing locally, and the reverse happens after a large sync pulls everything down.
- Application caches that never get pruned. Browsers, Xcode, Docker, and design tools all keep multi-gigabyte caches with no upper bound and no cleanup schedule.
- Log and diagnostic data. A crashing daemon can write tens of gigabytes into /private/var/log over a weekend without any visible symptom besides the disk filling.
How to get a real answer
The reliable move is to measure actual on-disk usage per directory rather than trusting a summary. A treemap makes this obvious in a way a list never does, because a single 40 GB directory is a single large rectangle instead of one row you have to scroll to.
Burrow's Analyze tool walks the filesystem and renders a squarified treemap of what it finds, so the thing consuming your disk is the biggest shape on screen. Drill into a branch to see the same breakdown one level down, then reveal the offender in Finder or send it to the Trash from the context menu. Because it measures real allocated bytes, the numbers it shows are the ones you actually get back.