Mac Storage Numbers Don't Match — Here's Why

You open About This Mac, see 8 GB free, then open a Terminal and df -h reports 45 GB available. Finder's status bar shows something else entirely, and Disk Utility has its own opinion. If your mac storage numbers don't match across these tools, you are not misreading anything — the tools are genuinely measuring different things, and the gap can be tens of gigabytes. Here is what is actually going on and how to get a number you can trust.

Why the Same Drive Shows Four Different Numbers

Every modern Mac uses APFS (Apple File System), introduced with macOS High Sierra. APFS brought several features that make storage accounting genuinely complicated: a shared container pool across multiple volumes, purgeable space, and sealed system snapshots. Each tool you reach for taps into a different layer of that stack.

1. About This Mac / System Settings Storage

The bar graph in About This Mac (or the Storage section in System Settings on macOS Ventura and later) is the most optimistic readout. It subtracts purgeable space from "used," treating it almost as if it were already free. Purgeable space includes iCloud-offloadable files, Safari caches, font caches, and other data macOS promises it can delete on demand. The OS considers this a safety cushion — you will never actually hit zero free space because macOS will purge automatically before that happens. The problem is that purgeable data is still physically on your SSD. If you copy a large file in Finder, macOS will purge as needed, but a third-party app trying to allocate space via standard POSIX calls might see far less room than About This Mac implied.

2. Finder's Status Bar

Open any Finder window, press Command-/ to show the status bar, and you get a "X GB available" figure. Finder queries the volume's available bytes using statfs(), which returns the same number the kernel exposes as available — this typically includes purgeable space because the kernel knows macOS can free it. The result is usually close to what About This Mac shows, but not always, because the Storage bar graph also calculates what it calls "System Data" (a catch-all for things it cannot cleanly categorize) in its own pass.

3. df in Terminal

Run this:

df -h /

The "Avail" column from df does not include purgeable space. It shows only the bytes the filesystem has already marked as unallocated. On a system where About This Mac shows 45 GB free (with 30 GB purgeable), df might show only 15 GB. Neither number is lying — they are just answering different questions. The complication is that df also reports against the snapshot that / is mounted from (disk3s1s1 on a typical Apple Silicon Mac), not the Data volume where your actual files live. So the "Used" column from df / reflects the sealed read-only system volume, not your home folder.

To get a more useful picture from the command line, run:

diskutil apfs list

This shows each APFS volume's "Capacity Consumed" and the container's total free space separately, which is closer to the truth than any single df invocation.

4. Disk Utility

Disk Utility shows used and available space for whichever volume you select in its sidebar. If you select the container (disk3) rather than a volume, you see the container-level free space — the true unallocated bytes shared across all APFS volumes. If you select the Data volume (disk3s5) instead, you get that volume's consumed space without a useful "free" figure because free space belongs to the container, not to any individual volume. Many users click the wrong item and end up comparing apples to oranges.

The Biggest Culprit: Purgeable Space and "System Data"

Purgeable space is the single largest source of finder storage different from about this mac confusion. Here is what lives in it:

• Files stored in iCloud Drive that have been downloaded locally but can be offloaded
• Time Machine local snapshots (APFS stores these transparently and marks them purgeable)
• Safari browser cache and offline reading list
• CoreData and system font caches
• Optimized storage downloads (TV app, Music app offline content marked for removal)

Time Machine local snapshots deserve special attention. Every time Time Machine runs, APFS takes a local snapshot before the backup. These snapshots can accumulate to many gigabytes and are counted as purgeable, so they vanish from About This Mac's "used" column but are physically present. You can see them with:

tmutil listlocalsnapshots /

"System Data" in the About This Mac bar is a second source of confusion. It is a catch-all bucket that includes virtual memory swap files (/private/var/vm/), kernel extension caches, system logs in /var/log/, and anything the categorizer cannot assign to Apps, Documents, or iCloud. It is not unusual for System Data to show 20–40 GB and be almost impossible to decompose further using only Apple's built-in tools. This is precisely why many users feel like their mac says disk full but its not — the "used" space is real, but a significant fraction of it is caches and snapshots that will dissolve when space is genuinely needed.

A Side-by-Side Comparison

How to Get One Trustworthy Number

The most reliable way to assess your actual free space and understand where every gigabyte went is to get a breakdown that accounts for APFS volumes, snapshots, and purgeable data together — not to toggle between tools and add up conflicting figures.

1. Open Terminal and run diskutil apfs list. Look for "Capacity Not Allocated" under your container. That is the hard floor: bytes genuinely available to any volume or application right now.
2. Check local snapshots. Run tmutil listlocalsnapshots / and tmutil thinlocalsnapshots / 9999999999999 4 if you want macOS to aggressively purge them (this is safe — Time Machine will create new snapshots on the next run).
3. Inspect user caches manually. The largest user-space caches live in ~/Library/Caches/. Run du -sh ~/Library/Caches/* to see which apps are heaviest. Most subdirectories here are safe to delete with the owning app closed, but confirm what each folder belongs to before removing anything — some caches (like Xcode's DerivedData) are large and trivially safe, while others rebuild more slowly.
4. Use a disk-usage visualizer. A treemap makes the disk usage discrepancy mac immediately obvious because you can see exactly which paths are consuming space rather than relying on category labels that differ between tools. Crumb's whole-Mac audit does this in a single pass: it walks every APFS volume, labels purgeable space separately from hard data, and produces one consistent breakdown — which sidesteps the conflicting readouts from Apple's own tools entirely. If you want a fast answer without installing anything, du -sh /* run as root gives a rough top-level breakdown, though it takes a few minutes.

What Is Actually Safe to Delete

Once you know where your space went, the next question is what you can safely remove. A few rules of thumb:

• Safe with the owning app closed: ~/Library/Caches/ subdirectories for apps you still have installed. They will be rebuilt on next launch.
• Safe: Xcode's derived data at ~/Library/Developer/Xcode/DerivedData/ — often many gigabytes, always recreatable.
• Safe: Old iOS/watchOS simulators at ~/Library/Developer/CoreSimulator/Devices/ for runtime versions you no longer use. Check first with xcrun simctl list.
• Use caution: /Library/Caches/ (system-level). Most entries are safe, but some third-party drivers and VPN clients store persistent state here.
• Do not touch: /System/, /private/var/db/, or anything inside /System/Volumes/Preboot/. These are sealed or required for boot. Deletion is permanent and can require a reinstall to recover.
• Do not touch: Swap files in /private/var/vm/. macOS manages these exclusively; manual deletion causes kernel panics.

If you are unsure what a specific folder does, Crumb's "Is this safe to delete?" feature can explain any path in plain language and rate its removal risk before you commit — useful when you are deep in ~/Library/ and not sure whether a folder belongs to an app you still use. Cleaning is permanent on APFS without a Time Machine backup, so it is worth a second opinion on anything unfamiliar. You can download Crumb and run one free cleanup to see the whole-Mac breakdown without spending anything.

The Short Version

macOS storage numbers disagree because each tool counts purgeable space, APFS snapshots, and multi-volume containers differently. None of the built-in tools is wrong — they are just answering different questions. The practical takeaway: "Capacity Not Allocated" from diskutil apfs list is the most conservative and honest free-space figure. Anything above that is real data, some of which (caches, snapshots) macOS can reclaim on its own. A per-folder breakdown, either from du in Terminal or a disk visualizer, is the only way to understand the disk usage discrepancy mac well enough to confidently decide what to delete.