Half the confusion around Mac storage comes from vocabulary, not mechanics. System Settings, Disk Utility, and Terminal each use overlapping words for related-but-different things, and Apple's own interfaces are not consistent about which term means what. "Disk," "volume," and "container" get used almost interchangeably in casual conversation despite meaning three distinct levels of the storage stack. This article defines the terms you'll actually run into, in plain language, without assuming you already know the ones it hasn't defined yet.
SSD, disk, disk space, volume, and container
An SSD (solid-state drive) is the physical hardware — the actual chip-based storage device inside your Mac, or an external one plugged in. "Disk" is used loosely to mean the same physical device, though in Terminal and Disk Utility it can also refer to a logical representation of that device (you'll see identifiers like disk0, disk1). "Disk space" just means the total capacity of that physical device, measured in bytes and displayed in gigabytes or terabytes.
None of this tells you anything about how the space inside that physical device is organised — that's where volumes and containers come in.
A volume is a logical, mountable slice of storage that appears in Finder with its own name — the thing you'd historically call a "partition." On older filesystems, a volume had a fixed size carved out of the disk in advance.
APFS changed this by introducing the container: a container is the layer that actually owns the physical space on the disk, and it can hold multiple volumes that all share that same pool of free space dynamically, growing and shrinking as needed rather than being pre-allocated fixed sizes. On a modern Mac, your visible "Macintosh HD" and "Macintosh HD - Data" are typically two separate volumes living inside one shared APFS container. This is why they can report very similar free-space numbers — they're drawing from the same pool, not competing for separately reserved slices.
Snapshot
A snapshot is a point-in-time, read-only reference to the state of a volume, made possible by APFS's copy-on-write design. Creating one is cheap because it doesn't copy any data — it just records the current arrangement of data blocks. It becomes more costly to keep over time, as the live filesystem changes underneath it and the snapshot keeps old blocks from being freed. Time Machine uses local snapshots on your internal disk between real backups; you can list them with tmutil listlocalsnapshots /.
Crucially, a snapshot is not a backup: it lives on the same physical disk as the data it describes, so it offers no protection if that disk is lost or fails.
Purgeable space
Purgeable space is storage macOS is currently occupying with data it knows how to reclaim automatically when needed — mainly local snapshots and cached copies of iCloud content that could be re-downloaded. It counts as "used" in most displays right up until the system actually reclaims it, which is why it can make a disk look tighter than it functionally is.
Sparse file
A sparse file is one that has gaps, or "holes," in its allocated storage — regions the filesystem hasn't actually written physical blocks for, even though the file's nominal size suggests it should occupy that much space. A disk image or database file that was created at a large fixed size but only partially filled in is a common example. The result is that a file's reported size and its actual on-disk usage can differ substantially, and tools that only read the nominal size will overstate how much space that file is really costing you.
Hard link and symlink
A hard link is a second name pointing directly at the same underlying data (the same inode) as an existing file — not a copy, and not a reference to a path. If two hard links point at the same file, deleting one doesn't free any space, because the underlying data is still referenced by the other. A tool that isn't aware of this can double-count the same physical bytes once for each hard link it encounters, overstating total usage.
A symlink (symbolic link) is different: it's a small file that simply stores a path to another location. If the target moves or is deleted, the symlink breaks. Symlinks take up almost no space themselves and are not a source of storage confusion the way hard links are — they're closer to a shortcut than a second name for the same data.
Extended attribute
An extended attribute, or "xattr," is a small piece of metadata attached to a file outside its main content — a label the filesystem carries alongside the file rather than inside it. Common examples include com.apple.quarantine, which browsers attach to downloaded files as part of Gatekeeper's checks, com.apple.metadata:* entries used by Spotlight, and Finder tags. Extended attributes are usually tiny, but they're invisible in a plain file listing and can occasionally cause confusion when a file behaves differently than expected (a quarantine flag blocking it from opening, for instance) for reasons not visible in Finder.
Why the same word means different things in different places
System Settings, Disk Utility, and Terminal were built by different teams at different times, and none of them was designed to be the single canonical vocabulary for the others. System Settings talks about "Storage" categories that map loosely onto folders and app types. Disk Utility talks about "volumes" and "containers" in the APFS sense described above. Terminal tools like df and diskutil expose the rawest version of the same concepts, with identifiers like disk1s1 that don't obviously correspond to the friendly names shown elsewhere. None of these views is wrong; they're just different altitudes looking at the same underlying structure, and Apple has never fully reconciled the terminology across them.
Conclusion
Most Mac storage confusion isn't really about the filesystem being complicated — it's about the same handful of words being used slightly differently depending on which screen you're looking at. Once you have solid definitions for volume, container, snapshot, purgeable space, sparse files, hard links, symlinks, and extended attributes, most "why does this number not match that number" questions answer themselves.
If you want to see these concepts made concrete rather than abstract — which folders are actually sparse, where hard links are quietly avoiding double-counted space, what's sitting in purgeable versus genuinely used — that's the kind of detail VolumeLens is built to surface directly, rather than leaving you to infer it from a glossary.