APFS Snapshots on Mac: What They Are and How to Manage Them

You delete 40 GB of video files. The Trash empties. Free space goes up by exactly zero. That’s not a Finder bug — that’s an APFS snapshot doing its job, holding onto every byte you “deleted” because something else thinks it might still need them.

APFS, the file system Apple introduced in 2017 to replace HFS+, builds snapshots into its DNA. They’re how Time Machine works on the local drive, how some software updates roll back if they fail, and how third-party backup tools achieve consistent state. They’re also why your “free” space sometimes lies. Once you understand the model, the disk-space mysteries stop being mysteries.

What an APFS Snapshot Actually Is

A snapshot is a frozen, read-only view of a volume at a specific moment. It’s not a copy — APFS doesn’t duplicate files when it takes one. It just marks the existing data blocks as “still in use by snapshot X” so the system can’t reclaim them, even if the live volume’s view of those files changes or disappears.

This is called copy-on-write. When you modify a file that’s referenced by a snapshot, APFS allocates new blocks for the new version while keeping the old blocks intact for the snapshot. The snapshot continues to see the old version. Your live system sees the new version. Both are valid.

The cost: every block referenced by a snapshot is held against your free space, even if no live file needs it anymore.

Why Macs Take Snapshots

Three main producers of snapshots on a typical Mac:

1. Time Machine takes hourly snapshots of the boot volume. Even without a backup destination connected, your Mac keeps these locally so you can roll back recent changes.
2. macOS Software Update takes a snapshot before installing major updates so it can revert if something goes wrong.
3. Third-party backup tools — Carbon Copy Cloner, SuperDuper!, and similar — take snapshots to copy a consistent volume state without freezing the system.

There are minor producers too: some VM software, some sync clients. But for most users, those three account for nearly everything.

Listing Snapshots on Your Mac

Two commands tell you what exists.

For Time Machine snapshots specifically:

tmutil listlocalsnapshots /

You’ll see entries like:

com.apple.TimeMachine.2026-04-19-080015.local
com.apple.TimeMachine.2026-04-19-090012.local
com.apple.TimeMachine.2026-04-19-100009.local

The naming convention encodes the date and time the snapshot was taken. Each .local suffix indicates it lives on this machine (as opposed to a backup destination).

For all APFS snapshots, including non-Time Machine ones:

diskutil apfs listSnapshots /

This shows everything: Time Machine snapshots, third-party backup snapshots, system update snapshots. Output looks like:

+-> Snapshot d8f3...  com.apple.TimeMachine.2026-04-19-100009.local
|   Snapshot UUID:    D8F3A1B2-...
|   Snapshot XID:     12345
+-> Snapshot e1c4...  com.apple.os.update-A1B2C3D4

The com.apple.os.update-* snapshots are the system update ones. The com.bombich.ccc.* ones are Carbon Copy Cloner. The pattern tells you the producer.

Power users use SweepSweep handles all the cleanup that articles like this describe. Get Sweep free →

How Snapshots Show Up in Storage

This is where it gets confusing. Snapshots don’t appear as their own line item in System Settings → Storage. They show up as part of:

• System Data (most often)
• Available as “purgeable” (the system knows it can evict them)
• Macintosh HD size when calculated certain ways

The result: you delete files, Trash empties, and free space stays put because the snapshots still reference the deleted blocks. The Storage pane may even show that those blocks are now “purgeable” — meaning macOS will evict them automatically when something else needs the space.

In practice, “automatic eviction” is sometimes too slow. A big download can fail because the system didn’t get around to evicting fast enough.

Managing Time Machine Snapshots

Time Machine local snapshots auto-clean themselves on a few triggers:

• After 24 hours
• When free space drops below a threshold
• When a successful backup to your destination drive completes

You can manually trim them with tmutil:

sudo tmutil thinlocalsnapshots / 10000000000 4

That command tells tmutil to delete snapshots until at least 10 GB of free space is recovered, with urgency level 4 (the most aggressive — 1 is least urgent). Adjust the byte count for what you actually need.

To delete a specific snapshot:

sudo tmutil deletelocalsnapshots 2026-04-19-100009

Note the date format — just the date and time portion, not the full com.apple.TimeMachine. prefix.

To disable Time Machine local snapshots entirely on the boot volume:

sudo tmutil disable

That stops new snapshots being taken but doesn’t delete existing ones. To re-enable:

sudo tmutil enable

Disabling local snapshots breaks the “go back in time” feature even when your Time Machine destination is connected, so don’t do this unless you understand the trade-off.

Managing System Update Snapshots

These are the snapshots macOS takes before installing an update so it can roll back if the update fails. They have names like com.apple.os.update-A1B2C3D4. After an update completes successfully, macOS should clean them up, but it occasionally doesn’t.

To delete one (replace UUID with the actual one from diskutil apfs listSnapshots):

sudo diskutil apfs deleteSnapshot / -uuid A1B2C3D4-...

Third-Party Backup Snapshots

Carbon Copy Cloner names its snapshots com.bombich.ccc.*. SuperDuper! uses a different naming pattern. ChronoSync, Arq, and others each have their conventions.

For these, don’t delete via Disk Utility or diskutil — instead, open the backup app and tell it to clean up old snapshots through its own interface. The backup tool tracks which snapshots correspond to which backup states, and manually deleting one out of sequence can confuse the tool’s metadata.

If a backup app is misbehaving and leaving snapshots behind, there’s usually a “Snapshot Manager” or “Cleanup” option in its preferences. Check there first.

There’s a faster waySweep does this kind of cleanup automatically. Try Sweep free →

When Snapshots Cause “Disk Full” Despite “Free Space”

The classic scenario: free space looks fine but a write fails. Almost always, the actual container free space is much lower than the volume’s reported available space.

To see container-level free space:

diskutil apfs list

Look at the “Capacity Ceiling” and “Capacity In Use By Volumes” lines for the container itself. The difference is what’s truly free.

If the container is at 95%+ but volumes look fine, you have snapshots eating space. List them, identify the producer, and clean up appropriately.

Snapshots and Cloning, Migration, and Cloning

Two practical implications worth knowing:

Cloning a disk with snapshots — A block-level clone (like dd or asr asr restore) copies the snapshots along with everything else. A file-level clone (cp -R, rsync) doesn’t, because snapshots aren’t files in the user-visible sense. If you’re cloning to a smaller drive, file-level cloning is what you want.

Migration Assistant doesn’t carry snapshots over. The new Mac creates its own. Same for Setup Assistant restoring from a Time Machine backup — the new install gets a fresh snapshot history.

Browsing a Snapshot

You can mount a snapshot read-only and browse it:

mkdir /tmp/snap
sudo mount_apfs -s com.apple.TimeMachine.2026-04-19-100009.local / /tmp/snap

Now /tmp/snap contains the entire boot volume as it was at that snapshot’s moment. You can cd in, look at old versions of files, copy them out — anything but write to them.

When you’re done:

sudo umount /tmp/snap

This is occasionally useful when you’ve accidentally overwritten or deleted something and Time Machine’s UI is too slow to navigate.

Snapshots and Encryption

If your Mac uses FileVault, snapshots are encrypted along with the rest of the volume. They’re not a security hole — there’s no way to access snapshot contents without the volume’s encryption key. But they do count toward your encrypted-volume size.

When you turn off FileVault, the system has to decrypt all snapshot data along with all live data. This is one reason FileVault toggles take a long time on heavily-snapshotted volumes.

What This Means in Practice

The right mental model:

• Your Mac is constantly taking and pruning snapshots in the background.
• “Free space” is the number you see in Finder. Truly free space is what shows in df -h / or container-level diskutil apfs list output.
• Snapshots are usually fine — they protect you from data loss and make rollback possible.
• They become a problem when they consume so much space that legitimate operations fail.
• The right fix depends on the producer: tmutil for Time Machine, the backup app’s own UI for third-party tools, diskutil apfs deleteSnapshot for orphaned system update snapshots.

Snapshots aren’t something you fight with on a daily basis. But knowing they exist transforms a lot of “where did my space go?” mysteries into solvable problems.