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).
-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_placeoption is supposed to preserve xattrs, however.