Skip to content
WatermarkAudit

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.

Gmail and Google Drive returned the credential intact. Instagram and WhatsApp destroyed it completely, along with the file's declaration that AI had generated it. There was no partial survival in either direction.

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

ServiceCredential

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

Instagram

Posted to feed, downloaded from the post

PNG re-encoded to JPEG, 1.4 MB down to 201 KB, dimensions unchanged.

✕ destroyed

WhatsApp

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.

This is why the Gmail result is the most useful one here. Without it you might conclude that provenance simply cannot survive the internet. It can. It survives everything except being displayed.

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.

OperationCredentialSize

Copied or renamed

Same bytes, new filename

✓ survived641 KB

Resized to 50%

Scaled down, re-encoded

✕ destroyed35 KB

Re-encoded as JPEG

Same dimensions, quality 80

✕ destroyed49 KB

Screenshotted

Pixels captured, saved as PNG

✕ destroyed525 KB

Cropped

10% trimmed from each edge

✕ destroyed64 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.

Measured 13 August 20264 services5 transformation classes

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.