Photo software can store face coordinates and person names in XMP or IPTC-related fields. Inspect the complete metadata, separate identity data from rights information, and verify the exact files delivered by the publishing service.
Metadata Remover
Distinguish visible faces from embedded identity data
Photo managers and editors can detect a face and record its rectangle or center and size, a suggested category, a person name, and an application-specific identifier. These values may live in XMP regions or IPTC-related fields without appearing in an ordinary image viewer. The absence of a name label on screen does not make a photo anonymous. The visible face and the metadata that links that face to an identity are two separate disclosure paths.
Define the intended audience and the subject's consent before editing. Naming people may be useful in a private family archive but unnecessary in a public download or client handoff. Preserve the original in restricted storage and make a separate sharing copy. List which identity fields should be removed and which copyright, creator, caption, or licensing fields must remain so that privacy cleanup does not erase legitimate provenance by accident.
- Review pixels and identity tags separately
- Define audience and consent
- Work on a sharing copy
A recipient may be able to read a face classification even when the photo viewer never displays it.
Search PersonInImage and complete XMP regions
The IPTC Photo Metadata standard includes fields that can describe people shown in an image, while XMP region structures can describe named areas such as faces. Applications do not always use the same namespace or field label, and the same identity can be written into more than one block. Do not rely only on an operating system properties panel. Use a tool that reports complete XMP and IPTC groups, including nested structures and unknown fields.
Search for more than a display name. Email addresses, account names, contact records, internal person IDs, region types, and normalized coordinates can preserve a link to an individual. Coordinates may look like harmless decimal values while still allowing software to redraw a face box. Record the group and hierarchy of unfamiliar fields, then search titles, captions, keywords, filenames, and sidecar files for repeated names before deciding what to remove.
- Dump full XMP and IPTC groups
- Check names, IDs, coordinates, and region types
- Search captions and keywords for duplicates
Treat pixel redaction and metadata removal separately
Deleting a person name or face region does not hide the face in the pixels. If the publication requires visual anonymity, metadata removal alone is insufficient. The reverse is also true: covering a face does not remove a hidden name or region record. Verify both controls independently. Look beyond faces for badges, documents, vehicle plates, reflections, landmarks, and location clues that could identify someone from the surrounding scene.
For pixel redaction, use an opaque mask appropriate to the risk and flatten the final sharing image. Weak blur or coarse mosaic can retain recognizable shape and context, and an editable layered file may expose the original pixels. Reopen the flattened export at the size in which it will be distributed and inspect it at normal and enlarged views. Maintain separate checks for visual redaction and metadata cleanup so an approved result clearly shows that both paths were addressed.
- Audit face pixels and face tags independently
- Use opaque masking when anonymity is required
- Inspect contextual identity clues
A workflow may need both face redaction and face-name metadata removal; one does not perform the other.
Clean a copy and read it again
Run the metadata-removal step on the sharing copy, then inspect that exact output with the same full-report tool. Confirm that PersonInImage values, region names, region coordinates, custom IDs, and their containing XMP structures are gone where policy requires. Clearing only the text value or one namespace may leave a duplicate elsewhere. At the same time, verify that intentional copyright, source, and licensing information and the required ICC profile remain intact.
Open the cleaned file in at least two image applications and compare dimensions, orientation, colors, and any visual redaction. Check for embedded thumbnails or previews, because an older small image may still show an unredacted face or previous edit. Save the metadata report as evidence of the check rather than assuming every variation of the format is handled. If cleanup fails, rebuild a fresh copy from the preserved source instead of repeatedly editing the questionable derivative.
- Reinspect every relevant metadata group
- Check embedded thumbnails and previews
- Verify retained rights and color data
Verify the file the publishing service actually serves
Upload the approved copy to the real CMS, messenger, social platform, or client portal as a controlled test. A service may strip metadata from one rendition but retain it in an original download, thumbnail, or alternate size. Download each file a recipient can access and inspect it independently. Also confirm that caching has not exposed a previous version and review the public page for visible faces and contextual identifiers.
Document the restricted source location, removed groups, retained fields, visual masking method, tool version, and service results. The final practical check is to read full XMP and IPTC from every downloaded rendition and confirm that person names, IDs, and coordinates are absent while approved rights and color information remain. Apply the policy in bulk only after representative photos from different sources pass the same end-to-end test.
- Inspect originals, previews, and thumbnails
- Rule out cached older files
- Recheck downloaded XMP and IPTC
The audit is complete only when every derivative available to the recipient satisfies the privacy decision.
Key takeaways
- Face recognition results can be stored separately from the pixels as region coordinates, names, or internal identifiers.
- PersonInImage and XMP region structures may coexist, use different labels, or duplicate the same person's information.
- Removing a visible name is not enough if coordinates, custom IDs, thumbnails, or descriptive fields still reveal the association.
- Keep the source intact and verify both the cleaned copy and every derivative that a sharing service delivers.
Frequently asked questions
Can a photo application save face names inside the image file?
Yes. Depending on the application and settings, names and face locations can be stored in XMP regions or IPTC-related metadata.
Is deleting the person's visible name enough?
No. Check region coordinates, internal IDs, captions, keywords, sidecars, and duplicate namespaces for the same association.
Does blurring a face remove its metadata?
No. Pixel editing and metadata removal are independent operations, so each result must be verified separately.
Should copyright metadata be removed too?
Not automatically. Keep legitimate rights and provenance fields when policy requires them, while removing unnecessary personal identity data.
What should be checked immediately before sharing?
Download every rendition the service exposes and inspect its full metadata, thumbnail content, visible faces, and surrounding identity clues.