Original research · 7 min read
Which platforms strip content credentials?
Everyone repeats that provenance metadata is fragile. We took genuinely signed files, put them through real services, and measured what came back.
Short answer
Services that move files preserve everything. Services that display images destroy everything.
What we tested
Two Google-generated PNGs, each 1024×1024, each carrying a valid C2PA manifest signed by Google Media Processing Services and declaring trainedAlgorithmicMedia — meaning the file itself stated that generative AI had produced it. That last detail matters, because it is exactly the machine-readable disclosure that transparency regulation is pushing providers to attach.
Each file was sent through a service the ordinary way and retrieved the way an ordinary recipient would retrieve it, then audited again. Measured 13 August 2026.
Real services
| Service | Credential |
|---|---|
Gmail Attachment, emailed to self Byte-for-byte identical. The SHA-256 was unchanged, so the file that arrived was the file that left. | ✓ survived |
Google Drive Uploaded, then downloaded back Byte-for-byte identical, same as Gmail. The SHA-256 matched the original exactly. | ✓ survived |
Posted to feed, downloaded from the post PNG re-encoded to JPEG, 1.4 MB down to 201 KB, dimensions unchanged. | ✕ destroyed |
Sent using Message yourself PNG re-encoded to JPEG, 1.6 MB down to 264 KB, dimensions unchanged. | ✕ destroyed |
In both destructive cases the AI declaration was destroyed along with the credential.
The line is transfer versus rendering
The split is not about which companies are careful. It is about what a service does with an image.
Gmail and Drive treat your file as a file. They move bytes from one place to another without opening them, so everything inside survives. Both returned an identical SHA-256, meaning not a single byte changed in either case — the strongest form this result can take, since it leaves nothing to interpret.
Instagram and WhatsApp treat your file as an image. To show it in a feed or a chat they decode it to pixels and re-encode it at a size that suits them. Everything that was not a pixel is discarded in that step, and a content credential is emphatically not a pixel.
A detail worth pausing on
The WhatsApp file came back with more metadata fields than it started with — 10 before, 27 after — while every meaningful signal was gone. The re-encode discarded the provenance and wrote structural JPEG entries in its place.
Any tool that reports “metadata present” by counting fields would describe that stripped file as well documented. It is a good illustration of why a count is not evidence, and why our own audit reports what the metadata says — the camera, the software, the author — rather than how much of it there is.
What each kind of processing does
Separately, we put an Adobe conformance file from the official C2PA test set through each class of transformation, to isolate which operation is responsible.
| Operation | Credential | Size |
|---|---|---|
Copied or renamed Same bytes, new filename | ✓ survived | 641 KB |
Resized to 50% Scaled down, re-encoded | ✕ destroyed | 35 KB |
Re-encoded as JPEG Same dimensions, quality 80 | ✕ destroyed | 49 KB |
Screenshotted Pixels captured, saved as PNG | ✕ destroyed | 525 KB |
Cropped 10% trimmed from each edge | ✕ destroyed | 64 KB |
The result is unusually clean for an empirical test: there is no gradient. A credential is not weakened by processing, it is annihilated. That follows from the mechanism — C2PA signs a hash of the content, so one changed pixel invalidates the signature. The same property that catches a malicious edit also catches an innocent resize, and cannot tell them apart.
Note the screenshot row: it produced the largest of the four destroyed files while carrying the least information of any of them. File size tells you nothing about whether provenance is intact.
A separate image carrying full EXIF — camera make and model, editing software, author, copyright, GPS — showed the identical pattern. Every field survived the exact copy; every field was destroyed by all four pixel operations.
Why this matters
Once you have watched a valid credential vanish from a screenshot, a common and damaging argument collapses. Missing provenance is not evidence of anything. It is the expected outcome of nearly every path a file takes between its creator and you.
For publishers the implication is sharper. If your CMS resizes on upload — and most do — every credential attached upstream is being destroyed before a reader sees it. You can be scrupulous about signing and still ship files that prove nothing, without ever being told. Checking which stage of your workflow does it takes about a minute.
And for anyone relying on AI disclosure: in both destructive cases the declaration went with the credential. The provenance was correct at the point of creation and absent at the point of consumption, and nobody involved did anything wrong.
What this does not show
Being clear about the limits is what makes the rest worth reading.
- Each service was tested once, on one date, with one file. These are single observations, not averages.
- Platforms change their processing without announcing it. A result from August 2026 may not hold next year.
- Different upload paths within one service can behave differently — a story is not a feed post, and a mobile app is not a web client.
- We have not tested LinkedIn, X, Facebook, Slack, Discord, Signal, Telegram, or any CMS. We are not going to guess at them.
- One Telegram attempt was discarded because the captured file turned out to be byte-identical to the WhatsApp output, which means it was measuring the wrong thing.
Reproducing this
The transformation figures come from this site's platform survival test, which applies each operation in your browser and re-audits the output. Download the same Adobe test file, drop it in, and you should get the same table.
For a service, send a signed file through it, retrieve it, and put the two side by side in the comparison tool. The method and the full results are in the study notes. If you measure something that contradicts this, we would genuinely like to know.
Test your own pipeline
Run a published image from your own site through the survival test, or find which stage of your workflow is destroying provenance.