Every file on a Mac has two kinds of content: the data you actually think of as the file, and a set of small metadata records attached alongside it that most applications never show you. Those records are extended attributes, or xattrs, and they are how macOS quietly tags files as downloaded from the internet, colours them in Finder, and stores search metadata for Spotlight, all without touching the file's actual bytes. You have almost certainly triggered dozens of them today without noticing. This article explains what an xattr actually is, how to see the ones attached to any file yourself, which ones you are likely to encounter, and why they matter more in aggregate than they do individually.
What an extended attribute actually is
A file's main content lives in what is sometimes called its data fork — the bytes you get when you open it normally. An extended attribute is a separate, named piece of data attached to that same file but stored apart from the data fork, addressable by a key like com.apple.quarantine or com.apple.metadata:kMDItemWhereFroms. The filesystem tracks these as key-value pairs associated with the file's inode. Copying, moving, or backing up a file generally carries its xattrs along with it as long as the tool doing the copying is xattr-aware, which most standard macOS tools are; some non-Apple tools, and any transfer over a filesystem that does not support extended attributes, can silently drop them.
Listing what's actually attached to a file
You do not need any special software to see this metadata. Running xattr -l against a file's path prints every extended attribute key it carries, along with the (often binary) data for each one. It is a fast, safe way to answer "why is Finder treating this file oddly" or "did this actually come from the internet" without guessing — the attribute keys themselves are usually self-explanatory once you know the common ones.
xattr -l ~/Downloads/some-installer.dmg
An ordinary file you created yourself in a text editor will often show none. A file downloaded through a browser, tagged in Finder, or indexed by Spotlight will typically show one or more.
Finder tags are just an extended attribute
The coloured and named tags you assign to files in Finder — Red, Important, Work, or whatever labels you have set up — are not stored in some separate database that Finder maintains centrally. They live as an extended attribute directly on the file, under the key com.apple.metadata:_kMDItemUserTags. This is why tags travel with a file when you move it between folders on the same volume, and why a file's tags can survive being copied elsewhere entirely: the attribute is part of the file, not part of the folder it happens to sit in.
com.apple.quarantine: the best-known example
The most consequential xattr for everyday use is com.apple.quarantine. It gets attached automatically by the application responsible for bringing a file onto your Mac — a browser after a download, Mail after saving an attachment, Messages after receiving a file — and it is what triggers macOS's "are you sure you want to open this" prompt the first time you launch a downloaded app. It is purely metadata recording where a file came from and when; it is not the result of any scan, and removing it does not mean the file has been checked, only that macOS will stop asking about its origin. This attribute is common enough, and misunderstood enough, that it deserves its own explanation in more detail elsewhere.
com.apple.metadata: Spotlight's own bookkeeping
A whole family of xattr keys prefixed com.apple.metadata: exists for Spotlight and other apps to record structured information about a file directly on the file itself — where it was downloaded from, what application created it, or other indexable properties. Some of this data duplicates what Spotlight's separate index already stores, but keeping a copy directly on the file means the information survives even if the file moves to a volume with no Spotlight index of its own, or is copied somewhere the index has not yet caught up with.
Why the storage cost is tiny per file but adds up
Individually, extended attributes are cheap. A quarantine flag, a Finder tag, or a Spotlight metadata entry is typically a few bytes to a few kilobytes, and the filesystem stores small attributes efficiently rather than allocating a full block for each one. For a handful of files, or even a few thousand, the aggregate cost is not something you would ever notice against a modern drive's capacity.
The picture changes at scale. A photo library, a large project checked out from version control, or a Downloads folder with tens of thousands of items accumulated over years can carry extended attributes on a meaningful fraction of those files. Each one is small, but small costs multiplied by very large file counts stop being negligible, and — more importantly for troubleshooting — xattrs on system-adjacent files can occasionally interfere with tools that expect a clean state, which is a more common practical annoyance than the storage cost itself.
Removing an xattr deliberately
xattr also supports deleting a specific attribute (with -d) or every attribute on a file (with -c), and this is something people do deliberately when a known attribute is causing a specific, understood problem — most commonly clearing a stray quarantine flag on a file they trust. It is not something to reach for casually or in bulk across files you have not inspected, since you would be discarding metadata, including Finder tags, that you may actually want to keep.
Conclusion
Extended attributes are one of the more invisible parts of how macOS organises files, doing real work — tagging, provenance tracking, search metadata — without ever showing up as a separate item in Finder or eating a noticeable amount of disk space on their own.
They do matter, though, when you are trying to understand exactly what a file carries and why macOS is treating it a certain way, which is part of why we designed VolumeLens to surface this kind of detail rather than reduce every file to a single size number and nothing else.