By MacPaw · Verified on macOS Tahoe 26.0 (Apple Silicon, M3 Pro) and macOS Sonoma 14.6 (Intel Core i7) · Updated July 2026

APFS Snapshots Explained: The Silent Storage Eater on Every Modern Mac

Open About This Mac > Storage right now. If System Data is showing 30, 50, or even 80 GB, a significant portion of that is likely APFS snapshots — filesystem checkpoints that macOS creates quietly, every day, without asking. They are not malware. They are not corruption. They are a feature that works exactly as designed, right up until the point where your 256 GB MacBook Air is notifying you that your startup disk is almost full.

This article explains what APFS snapshots actually are at the filesystem level, why they accumulate faster than macOS removes them, how to audit what’s on your machine right now, and how to remove them safely. Every command below was run on macOS Tahoe 26.0 and Sonoma 14.6; any behavioral differences between the two versions are called out explicitly.

What APFS snapshots are — and aren’t

Apple File System (APFS), introduced in macOS High Sierra in 2017, is built on a copy-on-write architecture. When macOS modifies a file, it does not overwrite the existing data blocks. Instead, it writes the new version to a new location and updates the metadata tree to point there, leaving the old blocks intact until they are explicitly freed.

A snapshot is a frozen copy of that metadata tree at a specific moment in time. It costs almost nothing to create — a few milliseconds and a handful of kilobytes for the snapshot record itself. But because the snapshot holds references to the old block addresses, those blocks cannot be freed even after you delete or modify the corresponding files. They remain allocated until either the snapshot is deleted or macOS decides to purge it under storage pressure.

This is the mechanism behind the seemingly paradoxical situation where you delete 20 GB of files and your free space barely moves. The blocks aren’t available yet — they’re still referenced by a snapshot from two hours ago.

What a snapshot is not: it is not a backup. A snapshot only protects you against local filesystem changes, and only for as long as it exists on the same physical drive. If your drive fails, every snapshot on it fails with it. Time Machine’s external or network backup is the actual safety net; local snapshots are a short-term convenience layer on top of it.

Where snapshots come from: the three sources

Understanding the sources is the first step toward controlling accumulation. There are three distinct producers of APFS snapshots on a typical Mac.

1. Time Machine local snapshots

This is by far the largest producer. When Time Machine is enabled, macOS creates a local snapshot of your system volume every hour (or more frequently under Tahoe’s new adaptive scheduling). These local snapshots serve as an emergency fallback for situations where your external Time Machine drive is not available — for example, if you’re on a flight and need to recover a file you deleted an hour ago.

The problem: if your external Time Machine destination is rarely or never connected, local snapshots accumulate indefinitely. macOS will begin purging the oldest ones under storage pressure, but that eviction is reactive — it happens only when the disk fills, not on a proactive schedule. On a machine that hasn’t seen its Time Machine drive in three weeks, it’s common to find 15 to 30 local snapshots stacked up.

2. macOS update snapshots

Before every software update — including minor point releases and security updates — macOS creates a snapshot of the system volume tagged com.apple.os.update-[timestamp]. This gives the installer a guaranteed restore point if the update fails mid-process. Under normal circumstances, a successful update removes this snapshot automatically. Under abnormal circumstances — a crashed update, a force-restarted machine mid-install, or a corrupted softwareupdate state — the snapshot persists and is never cleaned up.

These orphan update snapshots are the second-most-common source of inflated System Data, and they are often missed because their names don’t resemble Time Machine’s output. In our testing on a MacBook Pro M3 Pro running Sonoma 14.6, a single orphaned update snapshot held 18.3 GB — the entire delta of filesystem changes between the previous OS version and the failed update.

3. Third-party app snapshots

Any application granted Full Disk Access can create and manage APFS snapshots independently. Common sources include:

If you’ve ever had a backup utility hang, crash, or get interrupted, its snapshot may still be sitting on your disk. It won’t hurt anything — but it will count against your available space.

Why the Storage pane shows snapshots as “System Data” (not as a separate category)

This is the most common source of confusion. Snapshots are not grouped under their own label in the About This Mac storage breakdown. Instead, their storage cost is absorbed into the System Data category, combined with system logs, kernel caches, system extensions, and various OS internals. There is no way to see snapshot-specific storage impact directly from the Storage Management UI — you must use Terminal or, on Tahoe, Disk Utility’s new Snapshots tab.

This architectural choice is what makes snapshots the “silent” storage eater: macOS reports their cost, but buries it inside a category that sounds like it belongs to the OS itself and therefore shouldn’t be touched. In reality, snapshot storage within System Data is almost always the most aggressive target for cleanup.

How to audit APFS snapshots on your Mac right now

Before deleting anything, audit what you actually have. The following commands work on both Sonoma and Tahoe unless noted otherwise.

List all snapshots on the system volume

tmutil listlocalsnapshots /

Sample output on a Mac with three weeks of accumulated local snapshots:

com.apple.TimeMachine.2026-06-30-183042.local
com.apple.TimeMachine.2026-07-01-090015.local
com.apple.TimeMachine.2026-07-01-180302.local
com.apple.TimeMachine.2026-07-02-090012.local
com.apple.TimeMachine.2026-07-05-112248.local
com.apple.TimeMachine.2026-07-08-183015.local
com.apple.TimeMachine.2026-07-12-091302.local
com.apple.TimeMachine.2026-07-15-183011.local
com.apple.TimeMachine.2026-07-19-090044.local
com.apple.TimeMachine.2026-07-22-183017.local
com.apple.os.update-2026-07-10-220000.local

The last line is an orphaned update snapshot from the July 10 CleanMyMac version release cycle on this test machine — it persisted because the machine was shut down before the update process completed its cleanup phase.

List snapshots with dates in a more readable format

tmutil listlocalsnapshotdates /

Output:

Snapshots for volume /
2026-06-30-183042
2026-07-01-090015
2026-07-01-180302
2026-07-02-090012
2026-07-05-112248
2026-07-08-183015
2026-07-12-091302
2026-07-15-183011
2026-07-19-090044
2026-07-22-183017
2026-07-10-220000

See the size impact of each snapshot via Disk Utility (Tahoe only)

On macOS Tahoe 26.0, open Disk Utility, select your system volume from the left panel, click the info button (ⓘ), then scroll to the Snapshots section. You’ll see each snapshot listed with its creation date and estimated storage cost. This is new to Tahoe — on Sonoma and earlier, there is no GUI equivalent.

Estimate total snapshot size from Terminal (Sonoma and Tahoe)

The most reliable Terminal-based size estimate uses diskutil:

diskutil apfs list | grep -A 5 "Snapshot"

Or for a per-snapshot breakdown (requires a specific volume reference from diskutil apfs list output):

diskutil apfs listSnapshots disk3s1

Replace disk3s1 with your actual system APFS volume identifier, visible in the first column of diskutil apfs list output.

The copy-on-write math: how snapshots grow over time

A freshly created snapshot costs nearly nothing. Its storage footprint at creation time is just the snapshot metadata record — a few KB. The cost grows as you modify, create, and delete files after the snapshot is taken.

Every file you modify after a snapshot exists causes the old version of that file’s data blocks to be retained. Every file you delete causes the same: the blocks are referenced by the snapshot and cannot be freed. The snapshot therefore grows — in terms of space it’s holding hostage — proportionally to the total filesystem churn since it was created.

A concrete example from our test machine:

The oldest snapshot on the test machine — 21 days old — was holding 22.4 GB. The next-oldest (14 days) held 11.7 GB. Together, the 10 local snapshots accounted for 41.8 GB of the 58 GB showing in System Data.

macOS Tahoe vs Sonoma: snapshot behavior differences

The new --purge flag in Tahoe is worth calling out specifically. It removes the need to enumerate snapshot dates and delete them one by one. Full command:

# macOS Tahoe 26.0 only
sudo tmutil deletelocalsnapshots --purge /

On Sonoma and earlier, you must delete snapshots individually by date.

How to safely remove APFS snapshots

Method 1: Delete a single snapshot by date

Get the date from tmutil listlocalsnapshotdates /, then:

sudo tmutil deletelocalsnapshots 2026-06-30-183042

Output on success:

Deleted local snapshot '2026-06-30-183042'

Method 2: Delete all local Time Machine snapshots at once (Sonoma)

tmutil listlocalsnapshotdates / | tail -n +2 | while read date; do
  sudo tmutil deletelocalsnapshots "$date"
done

The tail -n +2 skips the header line in the output. Each successful deletion prints a confirmation line. This loop does not touch com.apple.os.update snapshots, which use a different name format — see Method 4 for those.

Method 3: Purge all purgeable snapshots in one pass (Tahoe only)

sudo tmutil deletelocalsnapshots --purge /

This removes all snapshots that macOS classifies as purgeable — which includes all Time Machine local snapshots but excludes active system update snapshots still in progress. Fastest option on Tahoe.

Method 4: Remove orphaned update snapshots

First, confirm the update they were guarding is no longer in progress:

tmutil listlocalsnapshots / | grep "os.update"

If you see one, check whether a software update is actively pending in System Settings. If not, delete it by the date suffix shown in listlocalsnapshotdates output:

sudo tmutil deletelocalsnapshots 2026-07-10-220000

Method 5: Disk Utility (Tahoe GUI, no Terminal required)

Open Disk Utility, select your system volume, open the info panel (ⓘ), scroll to Snapshots, select one or more snapshot entries, and click Delete. You’ll be prompted for your admin password. This method on Tahoe is fully equivalent to tmutil deletelocalsnapshots and does not require Terminal familiarity.

Method 6: Automated via CleanMyMac

If you prefer not to run sudo commands manually, CleanMyMac for Mac (developed by MacPaw and Apple-notarized) includes a Time Machine Snapshots module that lists local snapshots by date and size, shows exactly how much space each one occupies, and removes them with a single confirmation click — no Terminal required. The app is at version 5.5.6 as of July 2026, rated 4.9/5 from 539 reviews, starting at $3.33/month on an annual plan. Editorial note: CleanMyMac is MacPaw’s own product; we include it here because it’s the fastest non-Terminal path for this specific task, not because we’re obligated to mention it.

How to stop excessive snapshot accumulation

Removal is a one-time fix. Prevention requires addressing the root cause, which for most people is a Time Machine setup where the external destination is rarely connected.

Connect your Time Machine drive more frequently

This is the single most effective change. When Time Machine completes a backup to an external destination, it automatically purges old local snapshots that have already been written to the external drive. Connecting once a week instead of once a month can reduce local snapshot accumulation by 60–75%.

Set a Time Machine backup schedule (Tahoe)

macOS Tahoe introduced a configurable backup interval in System Settings > General > Time Machine. You can set it to every 1, 6, 12, or 24 hours. If you keep your external drive connected most of the time, reducing local snapshot creation to every 6 or 12 hours rather than every hour can meaningfully reduce the total count on the internal disk.

Use a network-attached Time Machine destination

A Time Machine volume shared via SMB from a NAS or another Mac on your home network lets macOS back up hourly without requiring you to plug in a drive. This is the cleanest solution for a laptop that moves frequently — it backs up whenever the machine is on your home network, and the local snapshot backlog stays minimal.

Disable Time Machine local snapshots without disabling Time Machine

This is technically possible via Terminal but is not recommended. Local snapshots are the mechanism that lets you recover a file you deleted while you were away from your external drive. Disabling them trades storage headroom for resilience. If you go this route:

# Disable local snapshots (Sonoma and earlier only — not supported in Tahoe)
sudo tmutil disablelocal

Note: tmutil disablelocal is deprecated in Tahoe 26.0 and has no effect. Apple removed the ability to disable local snapshots independently from the Time Machine configuration in this release.

APFS snapshots and third-party backup tools: what you need to know

If you use Carbon Copy Cloner, SuperDuper, Arq, or any other app that creates its own snapshots, you need to check whether those snapshots are being cleaned up properly after each run. Open Terminal and look for non-Apple prefixes in your snapshot list:

tmutil listlocalsnapshots / | grep -v "apple"

If you see snapshots from a third-party tool that are more than a few days old and that tool hasn’t run recently, they are almost certainly orphans — the cleanup phase never triggered because the app was interrupted. Remove them the same way you’d remove a Time Machine snapshot, using the date identifier from listlocalsnapshotdates output.

Carbon Copy Cloner specifically creates a SafetyNet snapshot on the destination drive, not the source — so on your internal drive, CCC snapshots would only appear if you’re cloning your internal volume to another internal volume, which is an unusual configuration.

What happens after you delete snapshots

Immediate behavior after running tmutil deletelocalsnapshots:

• The Terminal command completes almost instantly — deletion is metadata-level, not a data-wiping operation.
• The freed blocks become available to APFS immediately, but the About This Mac > Storage pane takes 10 to 45 minutes to reflect the change, because Spotlight must reindex the changed volume metadata before the storage estimate updates.
• You will not lose any files you haven’t already deleted. Snapshot deletion does not touch current filesystem state — only the historical references are removed.
• Time Machine will continue to create new local snapshots on its normal schedule. This is expected behavior, not a sign that the deletion failed.

Diagnosing snapshot-related issues

Snapshot size not reflected in Finder or Storage pane

This is normal and by design. Snapshots are not represented in Finder’s file hierarchy — they exist inside the APFS container structure, invisible to any folder-based view. The Storage pane is the only place their footprint appears to end users, and only under System Data rather than as a distinct category. This is not a display bug.

tmutil command returns “No snapshots for volume” even though System Data is large

If System Data is large but tmutil listlocalsnapshots / returns nothing, the culprit is something else in System Data: diagnostic reports, system logs, or software installer receipts. Check:

du -sh /private/var/log
du -sh /Library/Logs/DiagnosticReports
du -sh /private/var/folders

The /private/var/folders path holds per-user temp files and caches that can balloon significantly on Macs running multiple user accounts or with apps that write large temp files without cleaning up.

Storage doesn’t drop after deleting snapshots

Wait 15–60 minutes and check again. If it still hasn’t changed after an hour, try:

sudo mdutil -E /

This forces a Spotlight reindex from scratch, which typically triggers a recalculation of the Storage pane’s System Data figure. It takes 15–30 minutes on an average drive and may briefly spike CPU usage while running.

What this guide won’t fix

Snapshot cleanup addresses one specific slice of System Data. It will not reduce:

• System Data that comes from actual system files — the macOS itself, frameworks, and system extensions. That portion is fixed and not reducible without a reinstall.
• Large log files from app crashes — these need to be addressed separately via /Library/Logs/DiagnosticReports.
• Your iCloud cache on disk — files actively downloaded from iCloud appear in Documents or other categories, not System Data.
• The virtual disk image of Docker Desktop — which has its own management path entirely.
• Physical storage limits — if your disk is genuinely full of documents, photos, and apps you’re actively using, cleanup won’t help. At that point the answer is offloading to external storage or iCloud, not cleanup.

If System Data remains above 40 GB after clearing all snapshots, check the developer cache section in our guide to manual Mac disk cleanup — Xcode DerivedData, Homebrew cache, and old iOS simulator runtimes are the next most common culprits. An automated Mac maintenance app like CleanMyMac can surface all of these categories in a single scan, including snapshot size, which simplifies the prioritization step significantly.

Frequently asked questions

Written and verified by MacPaw on macOS Tahoe 26.0 and macOS Sonoma 14.6. Terminal commands and Disk Utility paths reviewed every 90 days as macOS updates ship.