Some files on your Mac are smaller on disk than their contents would suggest, and it has nothing to do with a ZIP archive or an app you ran — it's APFS quietly compressing them behind the scenes. Transparent filesystem compression means a file can be stored compressed on disk while every program that reads it sees the original, uncompressed data, exactly as if compression weren't happening at all. Nothing in the read path changes: no decompression step in your code, no special API, no visible difference in Finder other than a smaller number when you check its actual disk usage. This article explains how that mechanism works, the extended attribute that marks a file as compressed, and why it can make your storage totals look inconsistent if you're not accounting for it.
How transparent compression works
The idea behind transparent compression is that the filesystem, not the application, decides to store a file's data in a compressed form, and reverses that compression automatically whenever the file is read. From the point of view of every app on the system — a text editor, a compiler, a media player — the file behaves like an ordinary, fully readable file. It has a name, a size, and content, and reading it returns exactly the bytes the application expects. The compression is entirely a storage-layer decision: the operating system compresses suitable file data when it's written, and transparently decompresses it on the way out when something reads it back.
This has been part of how macOS stores certain system files for years, originally introduced as a mechanism on HFS+ and carried forward conceptually into how the OS manages files on disk. Not every file is a good candidate — files that are already compressed (images, videos, archives) gain little or nothing from another compression pass, while text, some binaries, and other compressible content can shrink meaningfully.
The com.apple.decmpfs extended attribute
A compressed file needs some way to signal to the filesystem and any tool inspecting it that it isn't stored as plain, literal bytes. macOS does this through an extended attribute named com.apple.decmpfs, attached to the file. When this attribute is present, it tells the system the file's actual data is stored in compressed form and needs to be decompressed on read, rather than served directly. You can see whether a specific file carries this attribute using the standard extended-attribute tool:
xattr -l somefile
If com.apple.decmpfs appears in the output, the file is one that has been transparently compressed. Its absence just means the file is stored the ordinary, uncompressed way — the overwhelming majority of files on any Mac.
afsctool as a tool for inspecting and applying compression
Because macOS doesn't expose a simple built-in command for arbitrarily compressing your own files this way, a third-party command-line tool called afsctool has become the commonly used way for people to inspect and apply this compression themselves, outside of whatever the OS decides to compress on its own. It can report whether a given file or folder is using this HFS+/APFS-style compression, show the compression ratio achieved, and apply the same compression to files that aren't already using it. It's worth knowing this tool exists mainly because if you come across com.apple.decmpfs on files you didn't expect, or see compression ratios reported in a scan, afsctool is very likely how that compression got there, or how someone might go about auditing it.
Why a compressed file's on-disk size is smaller than a naive sum expects
This is where the practical confusion usually starts. If you sum up file sizes the naive way — reading each file's reported logical size and adding them together — you get a total that assumes every byte of every file occupies a byte of disk space. For a compressed file, that assumption is wrong: the file's logical size (what it reports, and what the application sees when it reads the file) can be considerably larger than what it costs on disk, because the actual stored data, compressed, is smaller than the data as read.
A folder containing a mix of ordinary and transparently compressed files will therefore have a real on-disk footprint smaller than the sum of the sizes Finder or a naive listing would suggest for each file individually. This isn't a discrepancy or an error in either number — it's the same distinction as logical size versus allocated size for a sparse file, just achieved through compression rather than unwritten holes. Any tool measuring "how much space would I get back by deleting this" needs to measure actual on-disk usage, not just add up reported file sizes, or its estimates will be systematically too high for compressed content.
What tends to get compressed in practice
Files most likely to carry com.apple.decmpfs in ordinary use are ones the operating system itself manages: certain system files and application resources that are naturally compressible and read relatively infrequently. Files you create and modify yourself — documents, photos, project files — are generally left alone unless something has explicitly compressed them, since compression only pays off for genuinely compressible data and the OS is conservative about where it applies automatically.
What this means for anyone measuring storage by hand
If you're trying to work out how much space a folder is really using without a dedicated tool, this is where manual size-adding falls down quietest. Two folders can report identical totals when you list the logical size of every file inside them, yet occupy noticeably different amounts of real disk space, purely because one folder happens to contain more compressible content that the system chose to store compressed. There's no visible marker in a plain folder listing to warn you of this — you would need to check each file's extended attributes individually with xattr -l, which is impractical across anything larger than a handful of files.
This is also why comparing a size reported by one tool against a size reported by another is not automatically an apples-to-apples exercise. A tool that sums logical sizes and a tool that measures actual disk blocks will legitimately disagree on a folder containing compressed files, and neither is wrong — they are answering different questions about the same data.
Conclusion
Transparent compression is one of those filesystem features that quietly does its job without ever announcing itself, which is exactly the point — it saves space without asking anything of the applications reading the files. The catch is that it makes naive size arithmetic unreliable: any tool that just adds up logical file sizes will overstate how much space a folder of compressed files is actually using.
We built VolumeLens to flag compressed files rather than silently mis-total them, so what you see reflects real disk usage rather than a sum of numbers that were never meant to be added that way. If you want the specifics of what it checks for during a scan, the features page covers this alongside the other filesystem details it accounts for.