Delete Local Time Machine Snapshots on Mac

StoragePublished July 28, 2026Updated August 2, 20269 min read

You delete a 20 GB export, empty the Trash, and available space barely moves. The instinct is to install a cleaner. More often the blocks are still held by local Time Machine snapshots on the startup volume. Storage settings fold that effect into System Data or a vague purgeable figure, so the grey bar stays large after you already did the sensible thing.

This is a lab-style guide: how APFS copy-on-write pins blocks, how to measure snapshots with system tools, what tmutil actually changes, and how to free space without erasing a real backup disk. When you finish, you should be able to tell snapshot pinning from a real missing-folder problem in under five minutes.

The wrong mental model

People treat free space as "sum of visible files." On APFS it is closer to "blocks with no remaining reference." A file can leave Finder and still leave extents referenced by a snapshot. Until the last reference drops, df keeps counting those blocks as used.

Three different numbers get mixed in conversation:

Number	What it answers
Finder / app "size"	Logical size of named files you can still see
`df` used/available	What the mounted file system reports after accounting rules
Storage "purgeable"	An upper bound on mixed reclaimable pools

Purgeable is not a folder. It can include local snapshots, some caches, evictable cloud content, and accounting slack. A tool that promises "free 47.2 GB of purgeable" without showing before/after df is guessing.

Under the hood: copy-on-write and snapshots

When Time Machine creates a local snapshot, the volume records a frozen view of extents. Later writes allocate new blocks. Old blocks stay alive while any snapshot still needs them. Deleting a file only removes the live volume's pointer.

That is why this sequence is common:

Record free space with df -h /.
Delete a large disposable file you control and empty Trash.
Free space barely moves.
tmutil listlocalsnapshots / still shows entries.
After a thin or delete of local snapshots, free space climbs (sometimes over minutes).

Apple documents local snapshots as automatically managed: created between external backups, kept for a short window, and thinned when space is needed. They help restore recent versions when the backup disk is unplugged. They are not a substitute for a full Time Machine history on external media.

A deleted file on the live volume still occupies blocks while a local snapshot references them; only after the snapshot is thinned do the blocks become free. — Deleting in Finder drops the live reference. Extents stay allocated until every local snapshot that still points at them is thinned or deleted.

Local snapshot names usually look like:

com.apple.TimeMachine.2026-07-28-091530.local

The .local suffix is the usual signal that this is an on-disk local snapshot, not a backup destination entry.

Local, external, and other snapshots

Kind	Where	What to do
Local TM snapshots on `/`	Startup volume	Thin with `tmutil` when capacity is tight
Time Machine backups	External or network volume	Real history; do not erase to fix internal free space
Other APFS snapshots	Same volume, different names	Only delete if you know the owner
iCloud Optimize Storage	Cloud + local materialization	Eviction policy, not `tmutil`

diskutil apfs listSnapshots / can show more than Time Machine alone. Other software can create APFS snapshots. Do not delete unknown non-TM snapshots with a random optimizer.

An APFS container divided into user files, snapshots, purgeable space, and free space. — Physical capacity is files, snapshots, purgeable data, and free space. System Data is a Storage classification, not one folder to empty.

Lab: measure before you delete anything

Open Terminal and capture a baseline. Write the numbers down; memory lies.

date
df -h /
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /
diskutil apfs list

How to read the output

Empty listlocalsnapshots. Local TM snapshots are not your problem. Map folders with du or a treemap (large files) and look at caches, Photos, Docker, or device backups.

Snapshots exist and free space is low. Pinning is plausible. Proceed to thin, then re-measure.

diskutil apfs list shows a container with several volumes. Free space is shared at the container level. A second volume can make one volume label look full while the container still has room, or the reverse. Always look at the container free space, not only the boot volume label.

Permission errors. Terminal may lack Full Disk Access for some protected trees. That is an access problem, not proof the disk is empty.

A controlled experiment

If you want proof on your own Mac:

Note df available bytes.
Copy a large disposable file (for example a disk image you can recreate) onto the internal volume, then delete it and empty Trash.
Compare df again within a few seconds.
List snapshots.
If free space barely moved and snapshots exist, thin, wait two minutes, df again.

You have just separated "file gone from Finder" from "blocks free for new writes."

What `tmutil` can do

Let the system thin first

If available capacity is only mildly tight, keep working. Installing updates, writing large files, or simply living near full often causes macOS to drop the oldest local snapshots without intervention. That path has the fewest side effects and preserves recent restore points longer.

Thin until a free-space target

tmutil thinlocalsnapshots can ask the system to reclaim up to a requested amount from local snapshots. Flags vary slightly by macOS version; check man tmutil on the machine you are fixing. Conceptually you are saying "free up to N bytes from local snapshots," not "delete this one named hour."

Use it when an installer needs headroom and you still prefer to keep newer local restore points if the system can.

Delete local snapshots for the volume

When the disk is critically full and listlocalsnapshots shows entries:

tmutil deletelocalsnapshots /

Some versions use date-based deletion of a named local snapshot rather than a single slash form. Prefer the documented form for your OS, then always re-list:

tmutil listlocalsnapshots /
df -h /

Expect free space to rise over seconds to a few minutes. APFS may release extents asynchronously. Sample twice.

What not to confuse with these commands

tmutil delete against a backup destination removes real backup history. Different operation, higher stakes.
Deleting folders under /.MobileBackups in Finder is not a supported cleanup path. Use tmutil or system reclaim.
Turning Time Machine off is not required to free local snapshot space and can leave you without a backup policy you still need.
Third-party "snapshot optimizers" that demand root without explaining the APFS model add risk without teaching you anything you can re-check with df.

Worked example (reading the story, not memorizing numbers)

Suppose after a weekend of video exports:

Storage shows System Data around 120 GB and purgeable "up to" 40 GB.
You delete 25 GB of exports and empty Trash.
df available rises by about 2 GB.
tmutil listlocalsnapshots / shows several .local entries from the last day.

Interpretation: most of the deleted export is still referenced by local snapshots. Thinning local snapshots is the next experiment, not wiping ~/Library at random.

After tmutil deletelocalsnapshots / (or a successful thin):

Snapshot list is empty or shorter.
df available climbs by tens of GB over a few minutes.
Storage's System Data number may lag or reclassify; trust df and real workloads.

If the snapshot list was already empty and free space still did not move, stop fighting snapshots. You have a different problem: large live folders, sparse files, clones, Trash on the same volume, or another volume in the container.

Why free space still may not rise after thinning

Even with local snapshots gone:

Other purgeable classes dominated the Storage estimate (cloud materializations, regenerable caches).
Sparse files and clones make logical and physical sizes diverge (why totals disagree).
Trash still holds the deleted items on the same volume.
A second volume in the APFS container shares the free pool.
A non-TM snapshot or a Time Machine destination still holds related data.

Each of those has its own measurement path. Snapshots are only one chapter.

Safety prerequisites

Before aggressive thinning:

Confirm a recent successful backup to external Time Machine or another restore path you have actually opened and tested.
Accept that intermediate local versions you delete cannot be restored offline until new snapshots appear.
Prefer documented tmutil over tools that cannot show a before/after free-space delta.

Local snapshots are normal. They become urgent only when the internal volume is full and recently deleted data is still pinned.

Common mistakes

Chasing the System Data number. The goal is usable capacity and a Mac that can update and save files, not a cosmetically small grey block.

Erasing the external backup disk because internal free space is low. That confuses local snapshots with backup history.

Deleting random Library folders because purgeable looked large. Purgeable is not a map of safe paths.

Measuring once immediately after thin. Wait and sample df again.

Ignoring container accounting. One volume label is not the whole story on APFS.

Where a review tool fits

A disk map such as Mole's Analyze view shows live folders well. It cannot turn System Data into one disposable directory. For snapshots, system commands remain authoritative.

Mole's Clean view can surface a local snapshots row when snapshots exist. It does not invent a precise per-snapshot GB total before the fact; after release it measures the change in free space. That matches the platform: reclaim is real, a fixed pre-scan promise often is not. Any cleaner that sells a large purgeable number without a measured delta is performing, not teaching.

Order of operations

Confirm a real backup path still exists.
Record df -h / and tmutil listlocalsnapshots /.
If snapshots exist and capacity is low, thin or delete local snapshots with tmutil, wait, re-measure.
If no snapshots remain, measure folders and clear owned caches or large user files by ownership.
Empty Trash only after you accept the removals.
Run the workload that failed before (installer, export, update) and confirm it fits.