Ask a Mac how big a file is and you can get two different, equally correct answers: the nominal size, which is the length of the data the file logically contains, and the on-disk size, which is how much physical storage the filesystem actually allocated to hold it. For most files these two numbers are identical, which is exactly why the distinction goes unnoticed until it suddenly matters — a folder that reports one total in Finder and a smaller or larger one in another tool, a "large" file that barely touches your free space, or a directory of tiny files that somehow costs far more disk than their sizes suggest. This article covers the three mechanisms that drive nominal and on-disk size apart, and why a storage tool worth trusting has to report both rather than picking one.
Filesystem allocation blocks
A filesystem doesn't hand out disk space one byte at a time. It allocates space in fixed-size units, usually called blocks, and a file's real footprint is always rounded up to a whole number of blocks, regardless of how many bytes the file actually contains. A file holding a single byte of data still consumes one full allocation block, because that's the smallest unit the filesystem can hand out — there's no such thing as allocating a fraction of a block to one file and the remainder to another.
This means the on-disk size of a small file is often larger, sometimes considerably larger in relative terms, than its nominal size. A 1-byte file might report a nominal size of 1 but occupy an entire block's worth of real disk space. This effect is most visible across large collections of very small files — thousands of tiny configuration files or cache entries can, in aggregate, cost noticeably more disk space than the sum of their nominal sizes implies, purely because of block rounding.
You can see a file's basic size metadata directly with stat:
stat somefile
Comparing that against the actual block usage reported by tools like du on the same path is a quick way to see allocation rounding in action for very small files, or to spot the opposite effect — a nominal size much larger than the real usage — for sparse or compressed ones.
Sparse files: on-disk size smaller than nominal size
Sparse files pull the ratio the other way. A sparse file has "holes" — logical regions of the file that were never written and therefore have no disk blocks allocated to them at all. Reading from a hole just returns zeroes; the filesystem never needed real storage there. This lets a file report a large nominal size — the full logical length it could contain — while its actual on-disk size reflects only the portions that have genuinely been written. Virtual machine disk images are a common example: a virtual disk can be created at its full configured size immediately, appearing to be tens of gigabytes, while its true on-disk footprint stays close to whatever the guest system has actually written so far.
Transparent compression: on-disk size smaller than nominal size
APFS can also store certain files compressed, transparently, so that any application reading the file sees the full, uncompressed data exactly as expected, while the filesystem holds a smaller, compressed version on disk. This is a different mechanism from sparseness — there are no holes here, just data stored more efficiently — but it produces the same kind of gap: the nominal size (what the file logically contains, and what every reader sees) is larger than the on-disk size (what it actually costs in disk blocks). A file carrying the com.apple.decmpfs extended attribute is one that's being handled this way.
Why one number is never enough
Put these three mechanisms together and it becomes clear why reporting only one size figure for a file, or for a whole folder, is misleading in either direction. Report only nominal size, and you'll overstate how much space you'd recover by deleting sparse or compressed files — sometimes by a wide margin, since a "large" sparse VM disk might barely move your free-space number when it's actually deleted, having occupied far less than its nominal size all along. Report only on-disk size, and small-file allocation rounding, plus the general expectation that a file's size is what its size says it is, will make totals look inexplicably larger than a straightforward sum of reported sizes would suggest.
Neither number is more "true" than the other — they measure different things, and both are useful for different decisions. Nominal size tells you what the file logically contains. On-disk size tells you what deleting it would actually give you back. A storage tool that only shows one is making a silent choice about which question you're allowed to ask.
What this looks like in practice
Consider three folders of the same nominal size: one full of ordinary photos, one containing a single large sparse VM disk image, and one containing thousands of tiny cache files. Their nominal sizes might be identical, but their on-disk sizes will diverge sharply — the VM folder's real footprint could be a fraction of its nominal total, while the tiny-files folder's real footprint could exceed its nominal total once every file is rounded up to a full allocation block. Only a tool that measures and reports both numbers, rather than assuming they're interchangeable, will show you this accurately.
Conclusion
The gap between nominal and on-disk size isn't an inconsistency to be resolved — it's three independent, well-understood filesystem behaviours (block allocation, sparseness, and compression) each pulling the two numbers apart in their own direction, sometimes in the same file at once.
We built VolumeLens to report both figures rather than collapsing them into one convenient-looking total, because the difference is often exactly the information you need before deleting something. A folder that looks enormous by nominal size but costs almost nothing on disk is not worth your time to clean up; a folder that looks modest but is quietly consuming far more real space is exactly the one worth investigating.