Images & photos · Image Metadata Privacy Tool
Software Tags and XMP History: What a Photo Says About How You Edited It
· Why it matters
exif image-privacy image-editing
Beyond camera settings, photos record which software touched them, when, and sometimes every develop setting you applied. This post explains the Software tag, XMP media-management history and Camera Raw settings, and why you may not want a client or the public to read them.
The 'untouched' photo that listed its own retouching — how metadata contradicts a claim before anyone looks at the pixels
An image described as untouched can still name the application that last wrote it. The EXIF Software field is readable by this parser, while an XMP packet can carry richer editing information that the tool deliberately does not decode. The correct report therefore distinguishes a visible field from the mere presence of an opaque metadata packet.
The Software tag and its cousins — EXIF Software, XMP CreatorTool, and version strings that date your toolchain
Software is an IFD0 tag classified into the Software category and presented in the full table. DateTime can accompany it as the file’s last-written time, while DateTimeOriginal has a different meaning. These values are supplied by the writing application and can be stale or fabricated, so they describe file claims rather than prove an editing history.
XMP identifiers and history are not parsed by this tool
The workbook named xmpMM DocumentID, InstanceID and History as though this tool displays them. It does not parse JPEG or WebP XMP content, and its PNG reader is concerned with defined text and EXIF chunks. The cleaner detects supported XMP blocks for removal, but the interface must not invent a detailed history table it cannot derive.
Develop settings may exist in XMP, but are not displayed
Develop settings may be recorded in an XMP packet, but no repository code interprets Camera Raw settings or reconstructs adjustments. An XMP-present message is a warning that additional metadata exists, not an account of its properties. Use an XMP-aware editor when those values need to be archived or audited before cleaning.
Who reads this, and why it matters — clients checking for manipulation, competitors inferring your tools, and identifiers linking a leaked file to your archive
A client, colleague or automated indexer can read ordinary Software and timestamp fields when they remain. What any external observer infers is outside the tool’s proof. The practical question is whether delivery needs that metadata. If not, whole-block removal avoids selectively overlooking an opaque packet while preserving image data and rendering-critical colour information.
Worked example: inspect a Software tag and detect XMP presence
Inspect an exported JPEG: read Software and DateTime if present, then note that XMP is detected for removal even though its XML is not shown. Strip the file and review the removed list for APP1 Exif and APP1 XMP. Verification re-reads supported fields from the output; it cannot certify the meaning of XMP it never parsed.
What this does not cover — content-provenance systems that sign edits, and pixel-level forensic analysis of retouching
Metadata removal does not detect retouching in pixels, authenticate provenance or erase recompression traces. Colour profiles are kept and may include a description string. The tool also avoids malware, safety and anonymity claims. Use the cleaned result to limit documented metadata exposure, not to represent an edited image as unedited.
Takeaway: your workflow is your business — the Image Metadata Privacy Tool removes XMP and EXIF software fields before delivery, without altering the image
Your workflow is your business, but accurate disclosure still matters. Preserve the original and any sidecar needed for production records, create a delivery derivative, remove supported EXIF and XMP blocks and verify that derivative. This keeps the promise aligned with the implementation: readable fields and detected packets are handled, while unparsed history is never paraphrased as fact.