Time Machine local snapshots: why a disk looks full

The symptom

You delete 50 GB, empty the Trash, and the free-space figure does not move. Or Finder says you have 8 GB free while the Storage panel says 60 GB is available. Or `df -h` disagrees with both.

Nothing is broken. You are looking at APFS local snapshots and the "purgeable" space they create, and the three tools are each telling a different but defensible truth.

What a local snapshot is

When Time Machine is enabled, macOS takes an hourly snapshot of your startup volume and keeps it on that same volume — not on the backup drive. This is what lets you enter Time Machine and restore a file when the external disk is not connected, and it is what makes a botched macOS update recoverable.

A snapshot is not a copy. APFS is copy-on-write, so a snapshot is a reference to the blocks as they were at that moment. It costs nothing at creation. It starts costing space only as you change or delete files afterwards: the old blocks cannot be released while a snapshot still points at them.

That is exactly why deleting 50 GB appears to free nothing. The files are gone from your view, but a snapshot taken before the deletion is still holding their blocks. macOS keeps these for roughly 24 hours, plus one per successful backup, and thins them automatically under pressure.

Purgeable space, and why the numbers disagree

macOS calls space that it can reclaim on demand "purgeable". It includes snapshot-held blocks, cached iCloud files that are also in the cloud, and some caches. When an application asks for space, macOS purges what it needs and the write succeeds.

The three common tools count it differently. `df -h` reports raw file-system availability and does not know about purgeable space, so it is the pessimistic number. Finder's Get Info shows available space including purgeable, so it is the optimistic one. The Storage panel sits in between and adds its own caching, so it can be several minutes out of date.

None of them is wrong. If you want the authoritative view of what is held and by what, ask directly:

# Snapshots on the startup volume
tmutil listlocalsnapshots /

# Purgeable and available space, per volume
diskutil info / | grep -i "Free\|Available"

# Raw availability, ignoring purgeable
df -h /System/Volumes/Data

When to intervene, and when not to

Usually: do not. macOS thins snapshots automatically when free space runs low, and it does so before any write fails. The snapshots are also genuinely useful — they are the difference between "I deleted the wrong folder an hour ago" being an inconvenience and being a disaster.

There are two cases where intervening is reasonable. The first is when you need a large contiguous amount of space right now — installing a macOS update, restoring a big backup, creating a VM — and the automatic thinning has not caught up. The second is when you have just deleted something very large and want the space back today rather than tomorrow.

In both cases thin rather than delete outright. `tmutil thinlocalsnapshots` takes a volume, a number of bytes to try to reclaim, and an urgency level from 1 to 4; level 4 is the most aggressive.

# Try to reclaim 20 GB from the startup volume, most aggressive level
tmutil thinlocalsnapshots / 20000000000 4

# Delete one specific snapshot by its timestamp from listlocalsnapshots
tmutil deletelocalsnapshots 2026-09-08-101500

Deleting a snapshot removes your ability to restore files as they were at that moment. If you are about to do something risky, that is precisely the wrong moment to clear them.

Things that are not snapshots but look like them

A few other mechanisms produce the same "space I cannot find" feeling.

• iCloud Drive with "Optimise Mac Storage" keeps local copies until space is needed, then evicts them. Those local copies count as purgeable.
• Photos with "Download Originals" holds full-resolution originals locally; switching to Optimise makes most of them evictable.
• Swap and the sleep image in /private/var/vm are managed by macOS and can be several GB. Do not touch them; a restart clears what is clearable.
• Files still held open by a running process are not freed on deletion until the process exits — a common cause of "I deleted the log and nothing happened".
• The Trash is on the same volume. Nothing is freed until it is emptied.

Snapshots on a backup drive are a different thing

Two words get used for two different mechanisms, and conflating them leads people to delete the wrong one.

Local snapshots live on your startup volume, are taken hourly while Time Machine is enabled, and are thinned automatically after roughly 24 hours. They are the ones this article is about, and they are the ones consuming the space you were looking for.

Backups on the external drive are the actual Time Machine archive: full point-in-time backups going back months or years. They consume space on the backup disk, never on your Mac, and they are the thing you would restore from after a drive failure. `tmutil listbackups` lists them; deleting them frees nothing on your startup volume and reduces how far back you can go.

A useful check when the backup drive itself is full: `tmutil listbackups` plus `tmutil delete -d /Volumes/<drive> -t <timestamp>` removes a specific old backup. Time Machine also does this automatically, oldest first, so intervening is rarely necessary.

One more distinction worth knowing: turning Time Machine off does not delete existing local snapshots. They expire on their own schedule, so the space returns over the following day rather than immediately.

tmutil listbackups
tmutil destinationinfo

A working mental model

Think of free space on APFS as three layers: genuinely free blocks, blocks held only by snapshots (reclaimable in seconds, at the cost of your recent restore points), and blocks holding files you still have. A disk-space tool that reports only the third layer will keep confusing you.

Dropit reads snapshots and purgeable space alongside the file tree, so the disk gauge distinguishes what is actually used from what macOS is holding and could release — and the app tells you when a big deletion is being pinned by a snapshot instead of leaving you to wonder why the number did not move. Deleting snapshots requires administrator rights and is deliberately not something the app does for you; the article you are reading is the procedure.