Right-click your home folder, choose Get Info, and note the size. Then open System Settings → General → Storage and look at what it claims is "used". The two numbers will almost never match, and neither one is lying to you — they are answering genuinely different questions using genuinely different rules. Finder's Get Info walks visible files and adds up their sizes the way you'd expect. The Storage screen accounts for things Finder doesn't show you anywhere at all: purgeable snapshot data, cached iCloud content held in reserve, and space consumed by structures that aren't "files" in the sense Get Info counts. This article walks through the specific reasons the two disagree, so a mismatch stops looking like a bug and starts looking like the expected result of two different accounting methods.
Finder treats app bundles and packages as a single item
An application on macOS isn't really one file — it's a package, a folder structured to look and behave like a single file to the Finder UI, containing dozens or hundreds of actual files underneath (executables, resources, frameworks, localisations). When Get Info reports a size for an app, it is reporting the sum of everything inside that package, collapsed into one number attached to one icon. This isn't wrong, but it means Finder's per-item view can hide a lot of structure: a 2 GB "app" might be one line in a folder listing, while the same 2 GB spread across ordinary files would show up as dozens of visible rows. Storage's app-by-app accounting generally agrees with Finder here, but once you're comparing a whole folder that mixes packages and ordinary files, the aggregation differences start to compound.
Purgeable space: counted as used, but shown nowhere in Finder
The Storage screen has a category, sometimes labelled Purgeable, for space macOS considers reclaimable but is currently holding onto — typically local snapshot data and cached iCloud content that has already been uploaded and could be evicted locally if space got tight. Storage counts this as used space right now, because it genuinely occupies disk blocks right now, even though the system could free it automatically under pressure.
Finder has no equivalent concept anywhere in its size reporting. There is no folder you can point Get Info at that represents "purgeable space" — it isn't attached to any single visible file or directory, so Get Info on your whole disk, or on any folder within it, simply never accounts for it. This alone can explain many gigabytes of difference between what Finder totals for your visible files and what Storage says is actually used on the volume.
Local APFS snapshots holding onto deleted data
When you delete a file that's covered by a recent local APFS snapshot, the file disappears from Finder immediately — it's gone from every folder listing, and Get Info can no longer even see it to count it. But the snapshot itself, taken before you deleted the file, still references that data, and APFS can't reclaim the underlying blocks until every snapshot referencing them is also removed. Until that happens, the deleted file's bytes are still occupying real space on the volume, space that Storage's purgeable/used accounting reflects, but which is invisible to Finder because Finder only ever looks at the current, live filesystem state, never at what a snapshot is holding onto behind it.
You can inspect what snapshots exist directly:
tmutil listlocalsnapshots /
Each listed snapshot is a point-in-time reference that can be keeping recently deleted data alive on disk, entirely outside anything Finder will ever show you.
Extended attributes and metadata overhead
Every file on an APFS volume can carry extended attributes — small pieces of metadata attached to the file but stored separately from its main data, things like Finder tags, quarantine flags set by browsers on downloaded files, or Spotlight metadata caches. These attributes have a genuine, if usually small, storage cost of their own. Some tools that measure "size" work strictly from the file's data fork and never add in attribute overhead; others include it. Across a folder with millions of files, each carrying a modest amount of extended attribute data, this difference stops being negligible and starts showing up as yet another reason two tools measuring "the same folder" produce different totals.
Why the numbers were never going to reconcile exactly
None of this is a defect in either Finder or the Storage screen. They were built to answer different questions: Finder tells you what's on disk that you can currently see and act on; Storage tells you how full your disk actually is, including things that aren't visible files at all. A precise reconciliation would require Finder to start showing purgeable space and snapshot-held data as browsable items, which would be a strange and confusing user interface for what is, fundamentally, filesystem bookkeeping rather than user content.
What to do when the gap looks too large
A modest gap between Finder and Storage is normal and rarely worth chasing. A gap of tens of gigabytes is worth a closer look, and the snapshot list is usually the first place to check, since it is the one component of the difference you can act on directly. If tmutil listlocalsnapshots / shows several old snapshots and you have a Time Machine destination connected, letting a backup complete is often enough to let macOS reclaim the space on its own. If there is no destination connected and the snapshots are old, removing the oldest one directly with tmutil and reassessing the Storage total afterwards will tell you how much of the gap it actually explained, rather than guessing.
Conclusion
A mismatch between Finder's Get Info and the Storage settings screen isn't evidence that either tool miscounted — it's evidence that "how much space is this folder using" is a more layered question than it first appears, once snapshots, purgeable data, and metadata enter the picture.
We built VolumeLens to be explicit about which of these layers it's measuring, rather than presenting one number and letting you assume it matches whatever Finder or Storage happens to say. It walks the live filesystem the way Finder does, but flags the specific things — hard links, sparse and compressed files — that make naive size totals misleading, and it never silently zeroes a folder it couldn't fully read. The pricing page has details if you want to see what's included at each tier.