Metadata survival testing: what uploads and edits strip

Three metadata layers, three different deaths

An image file carries its metadata in separate containers, each handled by different code. EXIF is the camera layer, defined by CIPA DC-008: capture time, camera model, exposure, orientation and GPS position, stored as a binary block of tagged fields. XMP is the descriptive layer, an XML packet standardised as ISO 16684-1, where the IPTC Photo Metadata fields for creator, copyright, caption and rights live alongside editing history. The C2PA manifest is the provenance layer: a signed, hash-bound structure in its own container that records who made the file and what was done to it.

They survive differently because they are read differently. Most imaging libraries copy EXIF by default because the orientation tag is needed to display the picture correctly, so EXIF often outlives a resize. XMP is an opaque packet: some tools copy it, some rewrite it with their own history appended, some drop it. The manifest is bound to the exact bytes, so any tool that re-encodes the pixels invalidates it unless the tool re-signs, as the guide to testing a content provenance pipeline shows. One survival rate for the whole file describes nothing. Track three.

The test oracle: a hash per layer, an expectation per step

The oracle is a comparison of three hashes. Before each step, extract each layer from the probe to a canonical form (a sorted list of tag and value pairs for EXIF, the XMP packet serialised without whitespace, the manifest store bytes) and hash each one. After the step, extract and hash again. Equal hash: preserved. Layer absent: stripped. Hash changed with the layer still present: rewritten, which needs a field-by-field diff.

Write the expected outcome per channel per layer before the run: a resize, for example, should preserve EXIF apart from the pixel dimensions, rewrite XMP with a history entry, and strip or re-sign the manifest. If you cannot state an expectation for a pair you are exploring, which is fine if the report says so; fixing criteria first is the discipline of evidence-grade test records.

Metadata survival testing: the protocol

1. 1

   Build the probe set

   Create 12 images: 4 JPEG, 4 PNG and 4 WebP, half under 500 KB and half over 4 MB. Write a distinctive value into every field: a creator name that appears nowhere else, a capture time of 2001-02-03 04:05:06, a caption with a unique token, a GPS position in the sea. Attach a valid C2PA manifest to 6 of them.

2. 2

   Hash every layer

   Extract each layer from each probe to canonical form and record three hashes per file plus a SHA-256 of the whole file. Store the set read-only.

3. 3

   List the channels

   Ten is typical: the web upload form, the CMS media library and its derivatives, the resize step, WebP conversion, a messaging app, email as an attachment, email rendered inline, a social share, a screenshot on each operating system you support, and print to PDF.

4. 4

   Fix the expectations

   Write preserved, rewritten, stripped or re-signed for each of the 30 channel and layer pairs, and date the document before the first probe moves.

5. 5

   Run one channel at a time

   Push all 12 probes through a single channel, retrieve the output the way a reader would (download, save, export) and re-hash the three layers.

6. 6

   Classify and diff

   Record each of the 30 pairs with one of the three outcomes. For every rewritten result, diff the fields and list what changed and which component did it.

7. 7

   Check every derivative

   Where a channel produces several outputs (thumbnail, responsive sizes, share card, og:image), hash the layers of every one, since each is a separate file with its own metadata.

8. 8

   Report and schedule

   Publish the channel by layer table with counts out of 12, the diffs for rewritten cases and the tool versions.

Channel by layer: typical outcomes

Worked example: 12 probe images through 10 channels

A newsroom ran the protocol on the ten channels its photographs meet on the way to the reader. The counts are invented but realistic.

The upload form preserved all three layers on all 12 probes. The media library's derivatives rewrote EXIF on all 12 (new dimensions, new software tag), kept XMP on 9, stripped it on the 3 re-encoded WebP probes, and stripped the manifest on all 12; the resize step matched the library exactly, since it is the same code path. WebP conversion stripped EXIF on 8 of 12 and kept XMP on only 4, where a copy-metadata flag had been set for one size. The messaging app, the social share and both screenshots stripped every layer on every probe. Email as an attachment preserved everything; email rendered inline through the provider's image proxy stripped EXIF and the manifest and kept XMP on 3. Print to PDF produced a document with its own XMP packet and none of the probe fields.

Two findings mattered. First, 4 of the 12 WebP outputs carried a rewritten XMP packet in which the creator field had been replaced with the CMS service account's name: rewritten, with the rights line now naming the wrong party. Second, the og:image derivative, which nobody had listed as a channel, was a 1200 by 630 crop with no metadata at all, and it is the copy a reader of a shared link sees first. Against the 30 expectations written before the run, 23 pairs matched, 5 were worse and 2 were better.

Stripped, rewritten or preserved: how to report

Report each pair with one of three words and never collapse them. Preserved: hash equal, nothing to do. Stripped: the layer is absent, so the file carries no claim, a loss but an honest one, and the guide to verifying content credentials explains how to read absence. Rewritten: the layer is present with different content. Rewritten is the dangerous outcome, because the file still asserts a creator, a date or an edit history, and now asserts the wrong one with the same apparent authority as the original.

For rewritten cases the report needs the diff: which fields changed, from what to what, and which component did it. A converter that replaces the creator with a service account, or a library that sets the capture date to the processing time, is a rewrite that will be quoted against your organisation later. Severity follows the field's use: rights and attribution highest, then dates and locations, then technical tags.

Regression cadence and pitfalls

Metadata handling changes without anyone deciding it. A library upgrade, a CDN setting, a new output format or a CMS plugin update can move a channel from preserved to stripped with every functional test green. Run the probe set on every such change, and monthly for the channels you do not control (messaging apps, social shares, email proxies). Version the probe set with the test code and diff each table against the previous run.

• Testing only JPEG. PNG and WebP hold EXIF and XMP in different chunks, and a library that copies JPEG segments faithfully can drop PNG chunks. Every format your pipeline emits belongs in the probe set.
• Forgetting the derivatives. Thumbnails, responsive sizes, share cards and the og:image are separate files with separate metadata, and the smallest is the one most people see.
• Trusting the file name. IMG_4021.jpg says nothing about what is inside, and two channels can return the same name with different bytes. Identify probes by their distinctive values and by hash.
• Reading stripped as tampering. Most channels strip by default. Where a stripped layer removes a disclosure a policy or a law required, see testing AI disclosure labels.

The testing AI systems hub holds the detection guides for when nothing survived.

This guide is part of the testing AI systems hub. It is best read alongside testing a content provenance pipeline and evidence-grade test records for authenticity systems, which cover the neighbouring questions.