Run tmutil listlocalsnapshots / in Terminal on almost any Mac and you will see one or more entries, even if you have never plugged in a Time Machine backup disk. These are APFS snapshots — frozen, point-in-time records of your disk that macOS creates automatically — and they can quietly account for tens of gigabytes of the "used" space that nothing in Finder explains. This article covers what a snapshot actually is, why it costs almost nothing to create but can become expensive to keep, the two situations that produce them on a Mac, and the exact commands to list and remove one safely.

What an APFS snapshot actually is

An APFS snapshot is a read-only record of the exact state of a volume at one moment. It is not a copy of your files sitting somewhere else. APFS is a copy-on-write filesystem, which means a snapshot works by marking the disk's current arrangement of blocks and telling the filesystem not to overwrite them while the snapshot exists. Taking the snapshot itself is close to instantaneous, because no data actually moves at that point.

This is also why a fresh snapshot costs almost nothing. It is a reference, not a duplicate. The bill comes later.

Why snapshots get expensive later, not immediately

Once a snapshot exists, anything you subsequently change, move, or delete cannot have its old blocks reused straight away, because the snapshot still points at them. APFS has to keep those old blocks around until every snapshot referencing them is gone. A snapshot taken on a disk where nothing changes afterward costs essentially nothing extra. A snapshot taken just before you edit a large video file, rebuild a database, or reinstall a lot of software becomes an anchor holding onto an increasing amount of now-orphaned data, because the "before" version of every changed block has to stick around.

This is the mechanic behind almost every "my snapshots are eating my disk" report: not the snapshot itself, but the churn that happened after it was taken.

Two kinds of snapshot you will find on a Mac

Most snapshots you will encounter fall into one of two groups:

  • Time Machine's automatic local snapshots. macOS takes these on your internal disk on its own schedule, whether or not a backup disk is attached, so that Time Machine can offer recent file history even with nothing plugged in. The specifics of how often these are taken and how long they normally stick around are worth their own explanation — we cover that in detail in a separate article on Time Machine's local snapshot behaviour.
  • Other snapshots. macOS itself sometimes creates a snapshot before a major system update, as a safety net so a failed installation can be rolled back. Some backup tools and disk utilities create a manual one with tmutil localsnapshot before doing bulk work on a volume. Developers occasionally create one deliberately for testing.

Both kinds show up in the same tmutil listlocalsnapshots output, and both behave identically from a storage point of view: retained blocks that macOS counts as used space until the snapshot is removed.

Why they show up as "used" rather than free

macOS classifies the space held by snapshots as purgeable — space it considers reclaimable when it actually needs to, rather than space that shows up as free right now. The Storage panel in System Settings counts purgeable space under "Used", not "Available", which is why two Macs holding the same files can report noticeably different used totals, and why deleting a large file sometimes does not move the used number at all. If a snapshot still references the blocks that file used to occupy, those blocks are not free yet — they are simply waiting for the snapshot that pins them to go away.

Listing the snapshots on your disk

Terminal will tell you exactly what exists:

tmutil listlocalsnapshots /

Each line is a snapshot identifier that includes a date and time, in a format like com.apple.TimeMachine.2026-08-05-091500.local. If you see several with dates close together, that is normal — it usually means Time Machine's hourly cycle, not a fault.

Removing a snapshot

To delete a specific one, pass its date portion to deletelocalsnapshots:

sudo tmutil deletelocalsnapshots 2026-08-05-091500

This needs sudo because removing a snapshot on the boot volume is a privileged operation. Use the exact date string from listlocalsnapshots — do not guess it. Deleting a snapshot frees the blocks that only that snapshot was holding onto; if a newer snapshot also references the same blocks, the space is not actually returned until that one is gone too, which is why deleting a single old snapshot sometimes frees less than you expect.

Removing a Time Machine local snapshot does not touch your real Time Machine backups on an external disk or network destination. It only removes one local recovery point.

Snapshots usually clean themselves up

In the ordinary case, you do not need to manage any of this by hand. Plugging in your actual Time Machine backup disk causes macOS to reconcile local snapshots against the completed backup and prune the ones it no longer needs, because the same data is now safely stored elsewhere. macOS can also purge snapshots on its own when the disk comes under real space pressure, since purgeable space exists precisely so the system has somewhere to turn. Manual deletion with tmutil is mainly useful when you want the space back immediately, rather than waiting for macOS to decide it needs it.

Conclusion / VolumeLens tie-in

Snapshots are a reasonable piece of engineering — cheap insurance against data loss, built on a filesystem designed to make that insurance nearly free until you start changing things. The trouble is entirely one of visibility: nothing in the ordinary Finder view tells you they exist, so the space they hold reads as an unexplained shortfall rather than what it is. Two Terminal commands and a bit of patience usually resolve the mystery completely.

We built VolumeLens because we needed the picture of a Mac's storage to be honest, fast, and safe — not a vague pie chart with a "System Data" slab that never explains itself. Snapshots are part of why that slab is opaque: they are real space, held by macOS rather than by any file you can see or move to the Trash, and no scanner — ours included — can walk inside one, because a snapshot is not a folder. What VolumeLens does instead is scan the real files and folders you actually have permission to see, report their sizes honestly (hard links counted once, sparse and compressed files flagged, unreadable folders labelled rather than shown as zero), and re-check every item immediately before it goes to the Trash. Download VolumeLens to see exactly what is using real space on your disk, and reach for tmutil for the part that isn't a file at all.