You buy a "512 GB" Mac, and Finder tells you the disk holds 494 GB. You delete 20 GB of files and the free space counter only moves by 4 GB. Neither of these is a bug. Both come from how macOS actually defines "free space" on an APFS volume, which is a more layered question than it looks. Reserved space, purgeable data, the shared free-space pool across a container's volumes, and a decades-old unit disagreement between storage vendors and operating systems all contribute to the gap between what you expect and what the Finder sidebar shows you. This article walks through each layer so the number stops feeling arbitrary.

Reserved space: why 100% is never reported as usable

APFS keeps a portion of the volume in reserve rather than reporting every physical byte as available to write to. This reserve exists so that filesystem operations — metadata updates, journal entries, the bookkeeping APFS needs to keep the volume consistent — always have somewhere to go, even when the volume is otherwise nearly full. Without it, a disk that hit exactly 100% used could become unable to perform the basic operations needed to free anything up, a genuinely bad state for a filesystem to get stuck in.

This reserve is not a fixed, documented number you can subtract yourself, and it is not something you should try to reclaim. It is part of how the filesystem stays operable under pressure. The practical effect is simply that "free space" as reported has already had this margin subtracted, which is one reason a fresh drive never shows quite the round number printed on the box.

Purgeable space: used until macOS decides otherwise

A second, larger layer is purgeable space. This is storage macOS could reclaim automatically when needed but has not reclaimed yet — mainly local APFS snapshots (see how Time Machine keeps them between real backups) and cached copies of iCloud-hosted files that macOS downloaded for quick access and could re-download later if needed.

Purgeable space counts as used in most of the places macOS reports storage, right up until the moment the system actually needs the room and reclaims it. This is the single biggest reason deleting files doesn't move the free space number by the amount you expect: if a chunk of what looked "used" was actually purgeable already, deleting an unrelated 20 GB file might only nudge the total, because the purgeable portion was never really the constraint.

The System Settings Storage screen tries to expose this by labelling a "Purgeable" category explicitly, which is worth checking before assuming your disk is genuinely tight.

Why the number changes depending on where you look

A related source of confusion is that macOS doesn't give you one single free space figure — it gives you several, from different tools, calculated slightly differently. The Storage pane in System Settings estimates category totals (Photos, Documents, System Data, and so on) using heuristics about file types and locations, and that calculation can take a noticeable amount of time to settle on a full drive, sometimes updating visibly as you watch it. Terminal's df -h reports the filesystem's own view of used and available blocks directly, without trying to categorise anything, which is why it tends to respond faster and more literally.

Neither of these is "the real number" and the other wrong. They are two different vantage points on the same underlying container: one trying to help you understand what is using space, the other reporting how much space is used without commentary. When the two disagree by a gigabyte or two, that's normal measurement noise from timing and rounding, not a discrepancy worth chasing down.

Per-volume space versus the shared container pool

Modern Macs don't format a disk as one simple partition. They use an APFS container, and inside that container, multiple APFS volumes — one for the system, one for user data, one for VM swap, sometimes more — all draw from the same underlying free space pool. This is a deliberate design: instead of pre-allocating a fixed size to each volume the way older partition schemes did, APFS lets every volume in a container grow and shrink dynamically, sharing whatever is left.

The practical consequence is that "free space" reported for a specific volume via a tool like df -h is really "free space in the container, viewed through this volume," not a hard allocation belonging only to that volume. Two volumes in the same container can both report the same free space total, because they are both looking at the same shared pool from different angles. This is normal and not a sign that space is being double-counted or hidden — it just means the old mental model of "each partition owns its slice" doesn't map cleanly onto how an APFS container actually works.

You can see this directly:

df -h

Volumes belonging to the same container will show very similar or identical "Avail" figures, because they're drawing from one pool rather than separate fixed allocations.

The GB versus GiB gap

The last layer is a unit definition problem that predates APFS by decades. Storage manufacturers label drives using decimal gigabytes: 1 GB equals 1,000,000,000 bytes, matching the SI definition of "giga." Operating systems, including macOS in places, have historically calculated and displayed storage using binary-influenced units, where what's often casually called a "gigabyte" is actually 1,073,741,824 bytes — a gibibyte (GiB) — roughly 7.4% larger than a decimal gigabyte.

That 7.4% compounds as capacity increases, which is why a "512 GB" drive can appear as roughly 476 GiB-equivalent when displayed in binary-influenced units, without a single byte having gone missing. Nothing was lost; two different definitions of the word "gigabyte" were used at two different points in the pipeline — one on the box, one in the display. It is a labelling convention mismatch, not a storage bug, but it is genuinely confusing if you don't know it's happening.

Conclusion

None of these four layers — the filesystem's operating reserve, purgeable data waiting to be reclaimed, a shared container pool spread across volumes, and the decimal-versus-binary unit gap — are things you can meaningfully control or need to fight against. They are a normal, explainable part of how APFS and macOS report storage, and once you know they exist, a "missing" 20 or 30 GB stops being mysterious.

What you can control is how clearly you can see what's actually using the space that is genuinely yours to manage. That's the problem VolumeLens is built around: showing real, on-disk usage per folder so you can tell the difference between space you can free up yourself and space the system is holding onto for its own reasons.