Why deleting files does not free space on a Mac

Free and available are different numbers on APFS. When you delete a file, the space it used can stay pinned by a local Time Machine snapshot. macOS still counts it as available, because it could release it if pressed. Nothing is broken. You are looking at honest accounting for a disk that keeps recent history.

The usual sequence is deleting something large, emptying the Trash and watching the free space figure barely move. One command tells you whether snapshots are the reason. Another releases the space. The order you do things in matters more than either.

What purgeable space on a Mac actually is

Purgeable space is occupied right now and reclaimable on demand. macOS adds it to the available figure on the reasoning that you could write there and it would clear the way for you.

The idea arrived with Optimised Storage in macOS Sierra. The snapshots that now dominate it came with High Sierra and APFS. Nothing about the behaviour has changed through Catalina, Big Sur, Monterey, Ventura, Sonoma, Sequoia and Tahoe, which is why advice from several years ago still broadly applies.

That is a reasonable design and it makes the numbers confusing. Finder counts purgeable space as available. Disk Utility reports what is genuinely free on the container. The gap between that and Finder's figure for Macintosh HD is the purgeable amount. Knowing the size of that gap tells you what is at stake. It does not tell you what is holding it, which takes one more step. If the bar itself is what confuses you rather than the gap, start with what is actually using storage on your Mac and come back here.

Why local snapshots hold on to your deleted files

Time Machine on APFS keeps snapshots on the startup disk itself, not only on your backup drive. One is taken roughly every hour and kept for about 24 hours. Each records the state of the volume at that moment, holding a reference to every block in use when it was taken.

Read more: Why a macOS update needs more space than it says.

Delete a file afterwards and it goes from your view immediately. The blocks cannot go anywhere, because the snapshot still points at them. They come back only when the snapshot goes.

This is copy on write doing what it is designed to do. It is also why the effect is largest exactly when you least want it. A big clear out opens the widest gap between what you deleted and what the disk lets go of.

How to confirm snapshots are holding the space

Nothing in this section changes anything on your disk. Start in Disk Utility if you would rather not open Terminal at all.

The first is in Disk Utility. Select the Data volume in the sidebar, then open the View menu and choose Show APFS Snapshots. If a list appears, you have them.

The second names them, with dates.

tmutil listlocalsnapshots /

The output is a list of entries like com.apple.TimeMachine.2026-08-04-142223.local. A long list means snapshots are almost certainly your answer.

An empty result is worth a second attempt before you conclude anything. Since the system and data volumes were separated, snapshots do not always report against the root path, so try the data volume directly.

tmutil listlocalsnapshots /System/Volumes/Data

Nothing from either means snapshots are not holding your space and the cause is elsewhere.

The dates matter more than the count. Snapshots are supposed to age out after roughly a day. Entries from last week mean the ageing has stopped. That is a different problem from having too many, with a different fix.

How to free the space safely

Five steps. The first two are the ones people skip.

1. Wait a day first. Snapshots expire on their own and macOS releases purgeable space when something needs it. A great many of these resolve themselves overnight.
2. Confirm a real backup exists elsewhere. Local snapshots are restore points. Removing them when they are your only copy of anything is the one genuine risk in the whole procedure.
3. Stop new ones forming. Set Time Machine to back up manually rather than automatically, so you are not clearing snapshots while more arrive.
4. Thin rather than delete. Ask for a specific amount and let macOS choose which snapshots to give up.
5. Re-measure before doing more. Thinning frees more than expected in most cases. There is no reason to remove restore points you did not need to.

You can do this without Terminal. The same Disk Utility view that lists snapshots will delete them. Select one and use the minus button. One user working through a backlog that way removed forty nine snapshots and recovered 360GB. It is slower than a single command. It also shows you exactly what you are giving up, which on balance suits most people better.

The tmutil commands in full

Thinning takes a volume, an amount in bytes and an urgency from 1 to 4.

sudo tmutil thinlocalsnapshots / 20000000000 1

If little is released, raise the amount before you raise the urgency. A larger request at urgency 1 is a safer experiment than the same request at urgency 4.

To remove one specific snapshot rather than letting macOS choose, a third command takes a bare date. The listing above returns full names rather than dates, so ask for dates directly.

tmutil listlocalsnapshotdates

Those come back formatted YYYY-MM-DD-HHMMSS, which is exactly what the delete command expects.

sudo tmutil deletelocalsnapshots 2026-08-04-142223

That is the precise option and the one to reach for when you know which snapshot is the problem. Thinning remains the safer default, because it leaves macOS to keep whatever it considers worth keeping.

Thinning is not a request macOS has to grant. It attempts to reclaim what you asked for and releases less than that. That is not a failure. Repeating the command with a much larger number is how people accidentally remove every restore point they had.

When Mac snapshots refuse to age out

Entries older than a day or two that refuse to clear point at something other than normal accumulation.

The usual cause is a backup that has been failing quietly. Snapshot expiry rides along with the backup cycle, so when backups stop completing, the cleanup that removes old snapshots stops running too. The disk fills while Time Machine reports nothing wrong.

Fixing the backup restores normal expiry. That is a better outcome than clearing snapshots by hand every few weeks.

One command reports what Time Machine believes it is doing, which is more useful than the switch in System Settings.

tmutil status

Check the destination is reachable and that backups have been completing, not only that Time Machine is switched on. A Mac can show it enabled for months while every run quietly fails.

What else counts as purgeable space

Snapshots are the common answer and not the only one. Much of the remainder lands in the bucket macOS labels System Data, which is measured as a leftover rather than counted. A separate question runs alongside this one. Whether the blocks a snapshot is holding could still be read back is covered in what happens to a file when you delete it on APFS.

Files that a syncing service keeps locally can count as purgeable too, since macOS knows the service could fetch them again on demand. That is why the figure sometimes moves without any snapshot activity at all.

The practical consequence is worth knowing. If tmutil lists nothing and a large gap remains between the two figures, snapshots are not the answer. Do not keep running thinning commands against a volume that has nothing to thin.

One setting is worth trying at that point. Turning off Optimize Mac Storage in iCloud settings, spelled that way in the interface, then restarting and turning it back on has cleared stubborn purgeable space for people who tried everything else. Nobody seems to know precisely why, which is a reason to try it late rather than early.

Two pieces of popular advice that do not work. Filling the disk with a large dummy file to force a purge was an older trick and it stopped working under APFS. And sudo purge clears memory caches rather than the disk caches people mean, so it does nothing for this at all, despite the name. Booting into Safe Mode and back is harmless and occasionally shifts things, which puts it somewhere between the two.

The short version

The number that looks wrong is correct. The file system is doing something useful with the space rather than losing it.

The sequence that solves most cases is short. Wait a day. Check whether snapshots exist. Confirm a backup exists somewhere other than this disk. Thin conservatively. Anything beyond that is troubleshooting a broken backup rather than managing storage. That is a more productive thing to be doing anyway.