A photo "cleaned" by a typical online EXIF stripper still tends to leak. GPS coordinates often disappear, the device name disappears, the timestamp disappears, and the user assumes the file is now safe. The camera body serial number, however, is still there, sitting in an XMP block the stripper never touched. So is the original capture software string, the editing app's history record, and a field labeled aux:OwnerName that contains the user's full name.
The tool isn't broken. It's an EXIF stripper, and it stripped exactly what it advertises. The problem is that "EXIF" is narrower than most people, including a fair number of the developers who wrote those strippers, treat it as.
What "metadata" actually means inside a photo file
A modern JPEG or HEIC file is a container. The pixel data is one part of it. Tucked alongside, in segments the image decoder ignores, are blocks of structured information written by the camera, the operating system, and whatever software has touched the file since. Different blocks follow different specifications. Some come from industry groups, some from camera manufacturers, some from ad-hoc consensus that grew up around tooling.
There's no single field called "metadata." There's a stack of them, layered together in the file, sharing a few common values but mostly carrying different ones. The reason a casually built stripper misses things isn't that it failed at its job. Its job was narrower than the marketing suggested.
EXIF: the standard everyone knows by name
EXIF stands for Exchangeable Image File Format, originally published by JEIDA (now JEITA) in 1995 and most recently revised as Exif 2.32 in 2019. The current spec is JEITA CP-3451F. EXIF data lives in JPEG and TIFF files inside specific application segments, primarily APP1, beginning with the identifier Exif\0\0.
EXIF defines the tags most people think of as metadata: camera make and model, ISO, shutter speed, focal length, original capture timestamp, and the GPS information sub-IFD. The spec is well-documented, the tag list is finite, and the structure is binary TIFF. Every photo metadata library handles it. When a tool says it strips metadata, EXIF is what it almost certainly strips.
The catch is that EXIF was designed for camera-recorded data. It doesn't cover what photographers and publishers add later, it doesn't cover what other operating systems write, and it certainly doesn't cover what camera vendors invented to differentiate their hardware.
IPTC and XMP: the standards EXIF was never going to cover
IPTC came first. The IPTC-NAA Information Interchange Model was published in 1991 and standardized as IIM in 1995, designed for press photo workflows: captions, credits, keywords, copyright statements. The fields newsroom photo desks needed. IPTC IIM data is stored in its own JPEG segment, also under APP markers, in a different structure than EXIF.
XMP, the Extensible Metadata Platform, was published by Adobe in 2001 and standardized as ISO 16684-1 in 2012. It is an RDF/XML payload, human-readable when you open the file in a hex viewer, and it can carry essentially arbitrary information. Adobe products embed editing history, Lightroom develop settings, copyright statuses, rating values, and contact details. So do Capture One, Affinity Photo, and any tool that respects the standard.
The reason XMP matters for privacy is duplication. It can mirror values that also live in EXIF. The GPS coordinates from EXIF can be repeated in exif:GPSLatitude inside the XMP block. The camera owner name from IPTC can be repeated in dc:creator. A stripper that targets EXIF and stops there leaves the duplicates intact. A photo can have its location "removed" while still carrying the same coordinates in a parallel field a few hundred bytes away.
MakerNotes: the proprietary blob most strippers leave behind
Inside EXIF is a tag called MakerNote, defined by the spec as a place for camera vendors to store anything they like in any format they like. The contents are technically EXIF data, but they are not parseable through standard tooling without vendor-specific decoders.
What lives in MakerNote depends on the camera. Canon stores the camera body serial number, owner name, and shutter count. Nikon stores the lens serial number and AF micro-adjustment values. Apple stores a long list of capture context tags, including motion data, scene classification, and an AppleMakerNote.RunTime field that records the precise nanosecond since device boot at which the shutter fired. A timing fingerprint, in other words.
Some strippers remove the entire MakerNote block when they strip EXIF. Some preserve it because it does not show up in their parser as something they recognize. The difference matters: leaving MakerNote in place can leak a camera body serial number even when every other identifying tag has been removed. That serial number is enough to connect any two photos taken by the same physical device.
ICC and C2PA: the layers that aren't quite metadata but behave like it
Two more layers ride along with photo files. The first is the ICC color profile, which describes the color space the image was captured in. ICC profiles aren't personally identifying on their own, but custom profiles can be. A profile generated by a specific monitor calibration tool on a specific date carries a creator string and a timestamp.
The second is C2PA, the Coalition for Content Provenance and Authenticity, whose 1.4 specification was finalized in 2024. C2PA embeds a signed manifest describing the file's editing history: which tools touched it, which actions were taken, and in some cases an originator certificate that ties the photo to a specific camera, account, or service. Adobe, Leica, Sony, and several phone manufacturers ship cameras and apps that write C2PA manifests. Many image processors now preserve them through edits, which is exactly the point. Provenance is supposed to survive.
For privacy, that is a problem. A photo carrying a C2PA originator signature is connected to whatever identity signed it, even after EXIF, IPTC, XMP, and MakerNotes have all been stripped. Most metadata strippers as of early 2026 don't touch C2PA, partly because the format is new and partly because some users actively want to preserve it.
Which standards each tool category actually handles
Putting the standards next to each other, here is what common photo metadata strippers do as of early 2026:
| Tool category | EXIF | IPTC | XMP | MakerNote | ICC | C2PA |
|---|---|---|---|---|---|---|
| Browser canvas re-draw | Strips | Strips | Strips | Strips | Depends on tool | Strips as side effect |
Server-side ExifTool -all= | Strips | Strips | Strips | Strips | Preserved unless targeted | Often preserved |
| OS "Remove Location Data" | GPS only | Preserved | Preserved | Preserved | Preserved | Preserved |
| "EXIF only" web stripper | Strips | Preserved | Preserved | Sometimes stripped | Preserved | Preserved |
| Social network upload pipeline | Inconsistent | Inconsistent | Often preserved | Stripped | Re-encoded | Increasingly preserved |
The canvas re-draw approach has the strongest privacy property almost by accident. It draws the pixels onto a new buffer and re-encodes the result, which means everything not in the pixel data is gone. EXIF, IPTC, XMP, MakerNote, and C2PA all disappear together. ICC profiles only survive if the tool explicitly carries them across, which is a color-accuracy concern rather than a privacy one.
The server-side ExifTool wrapper, despite being the most "powerful" approach on paper, can leave behind anything the operator does not explicitly target. Even with -all=, C2PA assertions are not always covered without additional flags. And of course the file went to a server, which for a privacy-driven user is already the wrong answer.
What this means for an ordinary photo
Most people stripping metadata aren't threat-modeling against state actors. They're trying not to publish their home address when they post a backyard photo to Instagram. For that goal, the practical takeaways are narrower than the standards landscape suggests.
First, an "EXIF stripper" that only handles EXIF leaves real identifying data in place. Camera body serial numbers, XMP-mirrored GPS values, and C2PA originator signatures can all survive. If a tool's documentation only mentions EXIF, assume the rest of it is intact in the output.
Second, an OS-level "Remove Location Data" toggle is a GPS-only filter. The iOS Share Sheet's option, for example, deletes the EXIF GPS sub-IFD and not much else. The device serial number, the capture timestamp, the software string, and any XMP block stay in the file.
Third, the only architecturally clean approach to removing everything is to re-encode the image from its pixel data and discard the file's auxiliary blocks. Canvas-based browser tools do this naturally, which is part of why they tend to be more thorough than their server-side counterparts despite being simpler under the hood.
If you want to see all of this on a photo of your own, without trusting an upload, Blank is an in-browser canvas-stripper that lays the metadata out by standard before stripping it.