Photo metadata stored outside the image file

Nearly every guide on this site, including the tool itself, works on one assumption: the information you want gone is inside the file, in a header or a chunk, and rebuilding the picture from its pixels leaves none of it behind. That assumption is correct, and it is also incomplete. A second body of information about your photo was never in the file at all. It lives in a parallel structure your operating system keeps alongside the file — a named stream, an extended attribute, a companion file, a catalogue row — and it is invisible to every metadata reader you have, unreachable by every image tool including this one, and completely unaffected by stripping the image. That produces two opposite mistakes. People see a downloaded-from-the-internet flag or an author name in a properties pane after a clean wipe and conclude the wipe failed. And people hand over a folder, a drive or an archive believing the photos are anonymous while a sidecar file beside each one lists keywords, captions and coordinates. This page maps where that outside information actually sits, how to read and clear it on Windows and macOS, and which transfers carry it.

Clean the inside layer first. MetadataWipe scans and rebuilds one JPEG or PNG at a time inside this page — no account, no upload required, and the file never leaves your device.

Open MetadataWipe tool

Three storage layers, and only one of them is the image

It helps to stop saying "metadata" as if it named one place. Information about a photo on your machine is spread across three layers that behave nothing alike.

Inside the image bytes. EXIF, XMP, IPTC, MakerNotes, colour profiles and PNG text chunks. This is the layer every metadata remover addresses, and the layer a pixel-level rebuild eliminates wholesale. It travels wherever the file travels, because it is the file.
Attached to the file but not in it. Extended attributes on macOS and Linux, named streams on NTFS. The file system stores these as separate records keyed to the same file. Your image viewer never sees them. They survive any edit to the picture, and whether they survive a transfer depends entirely on how the file is moved.
Beside the file. Sidecar files, photo library catalogues, search indexes and thumbnail caches. These are separate objects in their own right. They never travel with a single shared photo, which makes them harmless to a recipient and persistent on your own disk.

Filenames and file dates are a fourth near-miss in this family, and they have their own treatment in what your filename and file dates reveal after you strip metadata. The difference is that those two are visible to everyone by default. What follows is the part nobody shows you.

Windows: the stream that remembers where the file came from

On an NTFS volume a file is not one blob of data. Microsoft's file system documentation puts it plainly: all files on an NTFS volume consist of at least one stream — the main stream, the normal viewable file in which data is stored — and a file can carry additional named streams whose full names take the form filename:streamname:$DATA. Those extra streams, it notes, "are not normally visible, but can be observed from a command line using the /R option of the DIR command." So dir /r in a folder is the single most useful command here: it lists the hidden streams on your photos.

The stream you will actually find is Zone.Identifier, the mechanism known as Mark of the Web. Microsoft's documentation states that Mark of the Web "is added by Windows to files from an untrusted location, such as the internet or Restricted Zone. For example, browser downloads or email attachments," and that it "only applies to files saved on an NTFS file system, not files saved to FAT32 formatted devices." You can read the stream directly by running notepad yourphoto.jpg:Zone.Identifier at a command prompt, which displays a ZoneId value under a [ZoneTransfer] heading. Microsoft lists the mapping as 0 for My Computer, 1 for Local intranet, 2 for Trusted sites, 3 for Internet and 4 for Restricted sites — so a 3 means Windows recorded that this image arrived from the web.

Some downloading applications write additional lines into that stream recording the originating page or file URL alongside the zone number. Whether yours does is something to check with the Notepad command above rather than assume, because it varies by browser and version — and if it does, that stream is a record of where you got a picture, attached to the picture, that no metadata checker will ever mention. To clear it, open the file's Properties dialog and tick the Unblock checkbox on the General tab, or run the Unblock-File cmdlet in PowerShell; Microsoft describes both as removing the ZoneId value.

Worth noting without alarm: this applies to the clean copy you download from this page as much as to anything else. The export your browser writes to disk is a new file arriving from a web page, so on Windows it may pick up its own zone stream. The stream describes the download, not your photo, and it does not travel with the image when you attach it to an email — but if you are moving the file around a shared drive and want nothing extra on it, dir /r will tell you and Unblock will clear it.

macOS: "Where from" and the rest of the extended attributes

macOS keeps a comparable set of records as extended attributes, listable in Terminal with xattr -l yourphoto.jpg. The one worth knowing by name is kMDItemWhereFroms. Apple's own metadata attribute reference defines it as follows: it "describes where the item was obtained from. For example, a downloaded file may refer to the URL, files received by email may indicate the sender's email address, message subject, etc." Read that twice. On a Mac, a photo someone emailed you can be carrying the sender's address and the subject line of their message — not in the EXIF, not in anything a metadata viewer parses, but in an attribute attached to the file and surfaced by Spotlight and the Finder's Get Info panel.

Other attributes commonly sit alongside it: Finder tags, download quarantine flags, and application-specific records. The exact key names and behaviour change across macOS releases, so rather than memorising a list, treat xattr -l as the inspection step and xattr -c yourphoto.jpg as the clearing step for a file you are about to hand over. Strip the attributes on a copy, not on an original you still rely on, because some of them are doing useful work.

Beside the file: sidecars, catalogues and caches

The third layer is the one that catches people out when they share in bulk rather than one photo at a time.

XMP sidecars. A sidecar holds metadata for an image whose own format cannot or should not carry it. ExifTool's documentation frames it exactly that way — if the tags are not supported for your file type, "then a metadata sidecar file is an alternative". In raw workflows this is the normal arrangement: the original stays byte-identical and a .xmp file with the same base name accumulates ratings, keywords, captions, edit history and sometimes coordinates. Strip the image and the sidecar is untouched, because it is a different file.
Library catalogues. Photo apps keep their own database of everything they have ever imported: dates, places, albums, recognised faces, edit stacks. Removing the coordinates from a file does not remove the row, which is why a gallery can still show a location for a photo whose header you emptied. That is a database read, not metadata coming back.
Indexes and thumbnail caches. The operating system's search index and preview caches hold derived copies of both the picture and its old field values, refreshed on their own schedule. A stale thumbnail that still shows a pre-crop frame is the same phenomenon.

What travels, and what stays behind

The practical question is which of this follows a photo to a recipient. The general rule is that transfers copy the main data stream and nothing else, so most of the outside layer stays on your machine.

Email attachment, web form upload, chat message: the image bytes are sent. Streams and attributes on your local copy are not part of that, and a sidecar is a file nobody attached. The receiving system may add its own markers on arrival.
Copy within the same NTFS volume or Mac disk: the extra records generally come along, which is why an unblocked-then-recopied file can look inconsistent.
Copy to a FAT32 or exFAT USB stick or card: dropped, because those file systems have nowhere to store them. Microsoft is explicit that Mark of the Web is absent on FAT32.
Zip or other archive: depends on the tool. Some preserve attributes, some write them into extra entries, some discard them. Verify rather than assume if an archive is leaving your hands.
Handing over a folder or a whole drive: everything goes, sidecars included. This is the high-risk case and the one worth a deliberate pass.

A workflow that closes both gaps

Rebuild the image first. Clean the inside layer with a tool that re-encodes from pixels, then confirm the export rather than the original — the procedure is in how to verify metadata was removed.
Inspect the outside layer on the file you will actually send. dir /r on Windows, xattr -l on macOS. Ten seconds, and it ends the guessing.
Clear what you find. Properties → Unblock or Unblock-File on Windows; xattr -c on a copy on macOS.
Look next to the file. Same base name, different extension. If there is a .xmp beside the photo, read it before you decide whether it ships.
Re-check after the last copy operation, not before it, since the copy itself can add a fresh marker.
If you are sending a folder, flatten it. Export the images you intend to share into a new folder and send that. A clean export directory has no sidecars, no inherited attributes and no leftovers you forgot to look at.

Where this site's tool fits, and where it cannot

Stated precisely, because the boundary is the whole point of this page. MetadataWipe accepts image/jpeg and image/png only, one file at a time. When you choose a file, the browser hands the page a File object exposing the name, size, type, a last-modified value and the image bytes — and nothing else. Named streams, extended attributes, neighbouring files and your photo library's database are simply not in that object, and a web page has no route to them; that is the same sandbox boundary that stops any site from reading the rest of your disk. The tool then decodes the image, draws it to a canvas at the original pixel dimensions and exports a new file from that canvas, which is why every metadata structure that lived inside the source is absent from the result whether or not the scanner could name it. All of that happens inside this page on your own device.

So the division is clean: the bytes are the tool's job, and the layers outside the file are yours, with your operating system's own commands. Neither substitutes for the other, and knowing which one you are looking at is what stops a successful wipe from looking like a failed one.

Common mistakes and misconceptions

"Explorer still shows information, so the strip didn't work." A properties pane blends three sources into one list without marking the boundaries: fields from inside the image, file system values from the volume, and stream or attribute data attached to the file. Only the first group is metadata removal's job.

"A metadata checker would have told me." It would not. Metadata readers parse the image format. A named stream or an extended attribute is outside the format entirely, so a reader that walks every EXIF, XMP and IPTC structure in the file still reports nothing about it.

"Clearing the zone flag is a privacy step." Mostly it is not, for sharing. The flag describes how the file reached your machine and it generally does not travel onward. Clear it for tidiness or because a shared drive is involved, not because a recipient would otherwise read it.

"The raw file is untouched, so nothing about my edits is recorded." That is precisely what the sidecar exists to do. Leaving the original pristine means the descriptive work went into a companion file, and that file is often more informative than the header would have been.

"I deleted the photo from the app, so the record is gone." The catalogue row, the search index entry and the thumbnail cache are maintained separately and on their own schedule. Removing or cleaning a file does not reliably clear what was derived from it.

"Zipping a folder normalises everything." Archive tools differ in how they treat attributes and streams, and a folder you zip contains the sidecars you did not look at. Zipping is not sanitising.

Related guides

Frequently asked questions

I stripped the metadata but Windows still shows the file came from the internet. Did the wipe fail?

No. What you are looking at is almost certainly Mark of the Web, which Microsoft describes as information Windows adds to files from an untrusted location such as browser downloads or email attachments. It is kept in a separate named stream on the file called Zone.Identifier, not in the image data, so rebuilding the picture cannot remove it and reading the picture cannot reveal it. You can see the contents by running notepad yourfile.jpg:Zone.Identifier at a command prompt, which opens the stream and shows a ZoneId value under a ZoneTransfer heading. Microsoft documents the mapping as 0 for My Computer, 1 for Local intranet, 2 for Trusted sites, 3 for Internet and 4 for Restricted sites. To clear it, open the file's Properties dialog and tick the Unblock checkbox on the General tab, or run the Unblock-File cmdlet in PowerShell. Microsoft also notes the mark only applies on NTFS and is not present on files saved to FAT32 devices.

Can MetadataWipe remove extended attributes, alternate data streams or sidecar files?

No, and no tool that runs as a web page can. When you choose a photo, the browser hands the page a File object that exposes the name, the size, the type, a last-modified value and the bytes of the image itself. Named streams, extended attributes, neighbouring sidecar files and your photo library's database are not part of that object and are not reachable from a page, which is the same sandbox boundary that stops any site from reading the rest of your disk. So the honest division of labour is this: MetadataWipe decodes your JPEG or PNG and writes a brand-new file from the pixels, which removes every metadata structure that lived inside the image whether or not the scanner knew how to name it, and the layers outside the file stay exactly as they were. Those you clear with your own operating system, using the steps in this guide.

Does emailing or uploading a photo carry this outside-the-file information with it?

Usually not, because almost every transfer path copies only the file's main data stream. An email attachment, a web form upload and a drag into a chat window all send the image bytes, so attributes and streams attached to your local copy are generally left behind, and a sidecar file sitting next to the photo is simply a different file that nobody sent. That is good news for sharing and bad news for assuming. The recipient's own system may attach its own markers on arrival, which is why a file you sent clean can show a downloaded-from-the-internet flag on their machine. Archives and some sync clients are the exceptions worth checking: a zip tool or a sync folder may preserve or recreate extra attributes, and copying to a FAT32 or exFAT drive drops them because those file systems have nowhere to put them.

What is an XMP sidecar file and should I delete it before sharing a photo?

A sidecar is a small companion file that holds metadata for an image that cannot or should not hold it internally, and it is the standard answer in raw photo workflows where the original is left untouched. ExifTool's documentation describes a metadata sidecar file as the alternative when the format of the target file does not support the tags you want to write. In practice you see a second file with the same base name and a .xmp extension sitting next to the original, carrying ratings, keywords, captions, edit history and sometimes location. It is a separate file, so it never travels inside the image and it is not touched by stripping the image. If you are handing over a folder, a zip or a disk, review the sidecars as deliberately as the photos, because their contents can be more descriptive than the EXIF ever was. If you are sending one exported JPEG or PNG, the sidecar is not involved.

Start with the layer that travels. Rebuild your JPEG or PNG here — scanned and re-encoded in your browser, with nothing sent anywhere.

Try MetadataWipe free