Face tags and person names hidden in photo metadata

The difference matters because every habit people build around metadata is tuned to the wrong thing. Coordinates are indirect: they place a device somewhere, and it takes a step of reasoning to turn that into a statement about a person. A name needs no reasoning at all. It is already the conclusion that a determined stranger would otherwise have to work towards, sitting in the file, indexed, copyable, and readable by anything that can parse XMP.

It is also not your camera's doing, which is why it falls outside the usual mental model. Your phone never learned who anybody is. The names got there because at some point you, or a family member, or a colleague managing a shared library, confirmed a face suggestion in a photo application — once — and a piece of software then propagated that label across years of files. Nothing about that moment looked like writing metadata.

Where a name actually gets stored

There is no single field. Three separate, documented structures can hold a person's identity inside an image file, and a library that has passed through more than one application may carry more than one of them.

Region structures in XMP. ExifTool's tag documentation describes a family it labels XMP-mwg-rs, following an industry region schema published by the Metadata Working Group. The shape is a RegionInfo structure containing a region list, where each entry carries a Name, a Type whose documented values include Face and BarCode, an Area expressed as X, Y, width, height and unit, and a Description. The area is proportional, so the file also records the dimensions those regions were applied to. Read plainly, one entry says: this rectangle, at these proportions of this image, is a person called this.

Microsoft's people tags. A separate XMP namespace, which ExifTool shortens to MicrosoftPhoto, documents its own region structure with per-person fields. The display name is the obvious one — RegionPersonDisplayName — but the documented siblings go further than a label: RegionPersonEmailDigest, RegionPersonLiveIdCID and RegionPersonSourceID, plus a date recording when the regions were considered valid. A digest is not a readable address, and it should not be described as one, but a per-person account identifier and a hash derived from an email address are identity material of a different order from "Mum".

The IPTC extension. The IPTC photo metadata standard, used across news, stock and publishing workflows, defines a property called Person Shown in the Image: Iptc4xmpExt:PersonInImage, a bag of text values, described in the specification as the name of a person shown in the image. The standard also defines a more detailed variant carrying a person identifier and description, and a separate Image Region structure with its own region boundary geometry. If your pictures have ever gone through a professional captioning pipeline, this is the slot that pipeline was designed to fill.

Alongside all three, names leak sideways into keywords. Photo managers routinely mirror people into keyword or hierarchical-subject lists, so a file can hold a tidy People > Family > branch that survives even where a region list does not. Treating keywords as harmless descriptive fluff is a mistake specific to this topic.

And a camera can contribute geometry without ever contributing a name. ExifTool documents an XMP group it labels apple-fi as face information written by the iPhone inside the region extensions, carrying angle values such as roll and yaw, and documents an Apple maker-note field, PhotosAppFeatureFlags, as set if a person or pet was detected in the image. Which devices and versions write which of those varies and changes, so the honest framing is: an untagged file may still record that a face was found and roughly how it sat.

Why this survives the checks people actually run

Four things line up to keep these fields invisible.

The first is the standards split. None of this is EXIF. An EXIF-only inspector, and there are many, reads a file with a dozen names in it and reports nothing — the general problem described in does removing EXIF also remove XMP and IPTC metadata, with the most consequential possible payload sitting in the part that gets skipped.

The second is that even XMP-aware software rarely shows regions as text. Photo managers consume these structures: they draw a box on a face and a name underneath, inside their own interface, which reads as an app feature rather than as file contents. There is no natural moment at which you scroll past a list that says "the following four people are named in this file".

The third is timing. Camera metadata exists from the shutter press, so people check for it near capture. Person tags arrive later — at import, at the moment you confirmed a suggestion, or on an explicit "save metadata to file" command that writes accumulated labels into every file in a selection at once. A photo you inspected and pronounced clean in 2023 can be carrying names written in 2025.

The fourth is that behaviour genuinely varies. Some applications keep face data only in their own catalogue and never touch the image; some write it out on export; some do it on a setting most people have never opened. That difference is real and it changes between versions, so neither "my app definitely writes names into files" nor "my app definitely does not" is safe as an assumption. The only reliable move is to open one file from your own library in a reader that shows XMP and look.

A workflow for a library that has been tagged

1. Test a real file, not a fresh one. A photo straight off the camera proves nothing here. Pick one that has lived in your photo manager for years and been through a face-tagging pass.
2. Look for regions and person fields specifically. Ask your reader for XMP in full, not an EXIF summary. You are looking for a region list, person display names, a Person Shown field, and any per-person identifier.
3. Check the keyword fields separately. Names often survive there after regions have been dropped, and keyword lists are frequently preserved by tools that discard structures they do not understand.
4. Find your write-back setting and decide it on purpose. Whatever it currently does, it should be a decision rather than a default you inherited.
5. Treat the names as belonging to the people named. You chose to label your sister's face for your own convenience; publishing that label is a disclosure about her, made by you, in a file she will never inspect. The wider version of that argument is in photo metadata when the photo is of someone else.
6. Clear by rebuilding, not by deleting fields. Field-by-field deletion requires that your tool knows about every namespace in the file. Re-encoding from pixels does not, because it starts from an image rather than from a container.
7. Re-check the exact file you are about to send. Not a sibling, not the one before the last edit — the bytes that are going.
8. Expect re-tagging. Drop a cleaned copy back into the same photo manager and it may be recognised and labelled again within minutes. Cleaning is an act on one file, not a property your library acquires.

What this tool does and does not do here

MetadataWipe takes a single JPEG or PNG, decodes it in your browser and re-encodes it from the resulting pixels, so the file you download is generated rather than copied and contains no inherited EXIF, XMP or IPTC block of any kind. Region lists, person display names, person identifiers and keyword branches all fall outside the new file for the same structural reason: none of the original container survives. JPEG output is written at a fixed quality setting, and the image is not resized or cropped.

The important caveat is about the check, not the clean. The before-and-after panel is a heuristic scan of the start of the file: it looks for a JPEG EXIF marker segment, for the literal text GPS, and for PNG text, timing and colour-profile chunks. It does not parse XMP, and it has no concept of a region or a person. A file carrying nothing but an XMP block full of names can therefore report "No obvious metadata detected" quite honestly — the names are removed by the rebuild regardless, but the panel is not what told you they were there. For seeing the names, use a full metadata reader.

It also handles JPEG and PNG only; a HEIC file, a RAW file, a sidecar or a video is rejected rather than cleaned, which bites here because tagged libraries commonly live in exactly those formats. And it cannot tell you after the fact whether a name was ever present. Your original is left untouched on disk, which means the copy you share has to be the one with -metadatawipe in its filename.

Common mistakes and misconceptions

"I removed the location, so the photo is anonymous." Coordinates imply; a name states. Of the two, the name is the more complete disclosure, and it is the one nobody checks for.

"My camera has no idea who these people are." Correct about names and not about faces. Detection geometry and a person-detected flag are documented camera-side fields, independent of anything you tagged.

"My metadata viewer showed nothing." Then check whether it parses XMP at all, and whether it renders region structures as readable text. Many do the first and almost none do the second.

"The tags only exist inside my photo app." That is one of the two possible behaviours, and which one you have depends on your application, its version and a setting. Once names have been written into a file, they travel with the file wherever it goes.

"Face tags are just a search convenience." They are also a structured list of the identified people in an image, with a bounding box for each — the exact thing an automated pipeline would otherwise have to infer.

"Cropping the person out removes their region." Regions are stored proportionally against recorded dimensions, so what happens on a crop depends entirely on whether the editing tool rewrites, recalculates, drops or blindly copies the structure. A stale region naming someone no longer visible is a real outcome. Do not rely on either result.

"I deleted the tag in the app, so it is gone." You changed a catalogue. Copies already exported, shared, backed up or emailed were written with the old contents and are not reached by that edit.

"An email address could not possibly be in a photo." The documented schema includes a per-person email digest field. That is a derived value rather than a readable address, and it is still more than a nickname.

Related guides

See also:

• Does removing EXIF also remove XMP and IPTC metadata?
• Photo metadata when the photo is of someone else