It seems to be an obvious question, but for some reason I cannot find an answer. Apparently, I just discovered a well-known MacOS feature: extended file attributes.

Context: When I download a file, I see that Finder shows "Where from" for a downloaded JPG file when looking up the file properties. However, once I've used exiftool to add an XMP/IPTC attribute (so something different), the "Where from" disappears. I undertsand that exiftools edits EXIF/XMP/IPTC tags, while "where from" is the extended attribute. However I don't understand why exiftool has an effect on it.

I wonder where this attribute is stored. I do not mind it being present of absent, but I want to avoid file modification as much as possible (for archival preservation reasons)---especially the uncontrolled modification. So, is it stored in the file, and exiftool deletes it though I didn't ask it to, or is it stored somewhere else in the file system, and in that sense its disappearance doesn't indicate the file modification?

  • 3
    EXIF attributes are not extended file attributes, they are two different things. If would be helpful if you could clarify what you are trying to do and what you have already tried. Please edit your question with that information. Commented Mar 2, 2023 at 15:47
  • 1
    exiftool by default writes a new file (and if you specify -overwrite_original, it will copy the new file over the original). extended attributes are properties of a specific file, and once the original file is deleted, so are its associated xattrs. where they end up being stored is a bit of an implementation detail based on the filesystem, but once it's overwritten the xattrs are effectively also purged. The -overwrite_original_in_place option is supposed to preserve xattrs, however.
    – vykor
    Commented Mar 5, 2023 at 9:12

3 Answers 3


Extended attributes are stored separately in the file system (such as APFS or HFS+).

This means that the extended attributes are not stored inside the main file data, so no file modification takes place when adding, removing or editing extended attributes. In fact you can add extended attributes to other file system objects than files - for example directories and symbolic links.

On macOS you can manipulate extended attributes from the Terminal by using the xattr command. In the following I'll demonstrate in a simple way that extended attributes are not stored inside the file data:

First we'll fire up Terminal.app and run the following commands to create a sample data file named testcontaining just the word "TEST" and calculating an MD5 checksum of its contents:

echo "TEST" > test
md5 test

You'll get the following result:

MD5 (test) = 2debfdcf79f03e4a65a667d21ef9de14

Now if you change the contents of the file in (almost) any way, you'll get a different MD5 checksum value.

Now we'll add an extended attribute named "test.attribute" with the value "value" to the file:

xattr -w test.attribute value test

We can confirm that the extended attribute is stored in the file system like this:

xattr -l test

This will read out that the "test" file has an attributed named test.attribute with the value "value".

Now rerun md5 to get the checksum of the file's contents:

md5 test

You'll see that you get the exact same MD5 checksum as before.

Historically, extended attributes were originally added to macOS as a file system feature in HFS+ with the release of Mac OS X 10.4 Tiger back in 2005. Even much earlier than that, Mac OS X had similar features that allowed storing extra data alongside files - for example in so called "Named Forks" and "Resource Forks". Those features dates back to eighties.

In modern day macOS, extended attributes are natively supported by APFS. If you look at Apple's reference documentation for APFS, you'll find that it specifies an object type APFS_TYPE_XATTR with a j_xattr_key structure, which basically contains the name of the attribute (for example "com.apple.quarantine"), and a j_xattr_val structure, which basically contains the value of the attribute.

In addition to the value of the attribute, the j_xattr_val structure also specifies exactly where the attribute data is actually stored in the file system. It can be either stored in a data stream (in extents for large attributes), embedded directly in the file system record (for small attributes), or handled directly by the file system (i.e. a specific attribute that has a dedicated structure for it in the file system - most prominently used for symbolic and firm links).

  • Thanks for the detailed and helpful answer. Can you please clarify why adding a tag with exiftool removes the extended attribute? Is there any logical explanation?
    – texnic
    Commented Mar 3, 2023 at 21:09
  • 1
    @texnic It depends on what exact exiftool command line you've used. Usually using exiftool will copy the contents of your original file, add its modifications, and save that out to essentially a new file (which might have the same name as the old one, and the old one being renamed to _original). As exiftool does not explicitly copy over the extended attributes by default, you won't see them on the newly created file.
    – jksoegaard
    Commented Mar 7, 2023 at 8:42

EXIF data is stored within the JPG, if you'd like to modify other EXIF attributes, you can keep the original date and time with this:






  • How does this answer the question about extended attributes?
    – nohillside
    Commented Mar 2, 2023 at 7:38

These attributes are stored totally separate from the file itself, in a special section of the disk volume. So adding, removing or modifying extended attributes does not alter the file in any way.

  • We are looking for high-quality answers based on fact and ideally supported by references. Answers should also actually address the issue the OP has. Can you improve your answer by adding details and references?
    – nohillside
    Commented Mar 2, 2023 at 7:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .