AI Content Provenance: Watermarks, Metadata, and What Survives Processing

AI-generated media does not carry one universal provenance marker. Depending on the output path, an image or video can contain a visible mark, an invisible watermark, ordinary metadata, a C2PA Content Credential, or no portable provenance at all. Processing can preserve one layer while removing another.

Then the file gets touched.

It is downloaded, stored, resized, cropped, transcoded, subtitled, recompressed, turned into a thumbnail, or uploaded somewhere else. The picture can still look right while part of its provenance has disappeared.

So the useful question is not only what the generator added. It is what reaches the final published asset.

generation
   ↓
original output
   ↓
storage / download
   ↓
crop / resize / transcode / edit
   ↓
published copy
   ↓
platform inspection

The provenance state can change at every arrow.

Five places AI content provenance can live

The word watermark gets stretched across several mechanisms that behave differently once the file is processed.

Mechanism	Where it lives	Primary job	Travels with the file?
Visible watermark	Rendered pixels or video frames	Human-visible disclosure or branding	While those pixels remain
Invisible in-content watermark	Image, video or audio signal	Machine detection	Depends on the watermark and transformation
Ordinary metadata	File or container fields	Descriptive source/tool information	Can be rewritten or stripped
C2PA / Content Credential	Signed provenance associated with the asset	Verifiable provenance assertions	Depends on the storage and processing path
Application/API record	Outside the media file	Internal generation traceability	No

Several can exist at once. A file may carry C2PA provenance and an invisible watermark while your own system separately stores the prediction ID and model used.

What can you learn from the file alone? You may be able to read ordinary metadata, validate a Content Credential, or detect a known invisible watermark. You cannot recover prediction IDs, internal model-routing history, or other generation records that were never embedded in or associated with the asset.

A visible watermark is rendered media

A logo in the corner of a video becomes part of the frames. It can identify the exporter, show a disclosure, or simply brand the asset.

That does not make it cryptographic provenance.

The each::video Watermark Overlay, for example, overlays a second image or video on the base video at an x and y pixel position. It is a composition and branding operation. The result is re-encoded; the capability is not documented as either a Content Credential generator or an invisible-watermark detector.

Visible marks are also physically straightforward. Crop out the corner and the mark can disappear. Cover it with another graphic and it can be obscured. Neither operation tells you what machine-readable provenance may still exist elsewhere in the asset.

Invisible watermarks live in the content signal

An invisible watermark is encoded into the image, video, or audio rather than stored only as a conventional metadata field.

Some deployed watermarking systems are designed to remain detectable after operations such as cropping, filtering, frame-rate changes, or lossy compression. The qualification matters: designed to remain detectable is not the same as guaranteed to survive every edit.

A normal metadata viewer will not tell you much here. If the output uses a proprietary in-content watermark, you need a detector that understands that watermark.

Content Credentials are provenance, not an AI classifier

C2PA uses a different mechanism. Its current specification groups assertions, a claim, and a claim signature into a C2PA Manifest. “Content Credential” is the preferred non-technical term for that manifest. Manifest Stores can be embedded in an asset or maintained externally.

C2PA is about provenance.

Validation can establish that the manifest is well formed, that the relevant cryptographic checks pass, and that the signed provenance has not been changed in a way that breaks validation. The standard also distinguishes a manifest being valid from the signing credential being trusted.

Neither tells you that the scene depicted is true.

And if a file has no Content Credential, that does not make it human-made.

C2PA is therefore not “special EXIF.” Ordinary metadata and cryptographically verifiable provenance have different trust properties.

What actually ships with a generated output?

There is no rule that every AI image gets field X or every AI video contains watermark Y.

Provenance is an output-path property.

One generation path may produce an invisible watermark. Another may attach C2PA provenance. Another may return ordinary metadata. A provider may support provenance for one modality or product but not another. Older outputs can differ from current ones too.

“This provider watermarks AI output” is therefore too coarse a statement for production engineering.

You need to know what happened to the artifact you actually received.

The provenance may be inside the media signal

This is the invisible-watermark case.

Detection requires a compatible detector, and transformation behavior depends on how the watermark was designed. A signal encoded into the media may survive a container change or re-encode that drops ordinary metadata.

Do not infer that from visual inspection.

If persistence matters, test the resulting artifact with the detector appropriate to that watermark.

The provenance may travel as file-level data

A generated asset can also contain information associated with the file or container.

Ordinary EXIF, IPTC, XMP, or container metadata can record software, timestamps, descriptive properties, or processing information. Applications can rewrite or discard those fields.

C2PA provenance works differently. Assertions, signatures, and bindings to the content let a validator check the provenance relationship instead of simply trusting a text field such as generator=AI.

Reading metadata is not the same operation as validating provenance.

The useful generation record may not be inside the file at all

Your application may know more about an asset than the JPEG or MP4 says.

prediction / trace ID
source model
model revision or version, where the provider exposes one
generation timestamp
original output reference
processing history
final output reference

That information belongs to your application record.

Send someone only the final file and they do not automatically receive the database row behind it.

This distinction matters when building on an API. each::api can return prediction results containing generated media artifacts, while each::storage can host media passed into later model or workflow stages. Being able to trace an asset back to a prediction inside your own system does not mean the same trace is embedded in every exported copy.

In practice, keep both:

1. portable provenance attached to, embedded in, or associated with the media, where available;
2. an application-side record of how the asset was produced.

They overlap, but they are not interchangeable.

Provenance can change even when the media still looks the same

This is where provenance stops being only a generator feature and becomes a media-pipeline problem.

Two videos can look identical to a viewer while carrying different machine-readable provenance. Visual preservation and provenance preservation are separate properties.

Canberk Sinangil, Co-founder & CTO: “Nobody writes a launch post about audio normalisation. Nothing ships without it.”

The same work that turns a model output into something publishable—cropping, captions, encoding, format conversion, delivery—is also where provenance can change. Post-generation processing is part of the provenance path, not cleanup after it.

Storage and ordinary file transfer

“Upload succeeded” tells you very little about provenance.

• Were the original bytes retained?
• Did the service normalize, recompress, or convert the asset?
• Did an export or delivery path create another representation?
• Was the provenance embedded in the asset, stored externally, or encoded into the media signal?

If a system preserves a file byte-for-byte, an embedded signal tied to those bytes has a much stronger preservation story. Once the system creates another representation, that assumption stops being safe.

Keep the original generator output as a reference artifact.

Transcoding and re-encoding

Transcoding deserves particular scrutiny because it deliberately creates another encoded representation.

In each::video, operations including crop, scale, overlay, watermark, reframe, captions, and several other transformations use a shared re-encoding contract. For MP4 output, the current default is libx264 video with AAC audio.

The resulting video can look exactly as intended while the provenance state has changed.

The current each::labs Terms of Service draw the same boundary. Customers may not deliberately remove, alter, or obscure provenance markings, watermarks, or Content Credentials embedded by a provider. The Terms also do not warrant that embedded provenance markings will remain intact through transmission or transcoding.

Those are two different responsibilities: do not intentionally strip provider provenance, and do not assume a normal media pipeline preserves it automatically.

C2PA-aware processing gives you another option. When an asset is modified, a provenance-aware tool can create provenance for the new asset and describe the original as an ingredient in that history. An ordinary encoder that knows nothing about C2PA should not be expected to do that work for you.

An invisible in-content watermark behaves differently again. Because the signal is encoded into the media rather than stored only as conventional metadata, it may survive an operation that removes file-level information. You still have to test the result.

Resize, crop, reframe, overlays, and subtitles

There is no useful universal answer to “does editing remove AI provenance?”

Take a crop.

A visible mark inside the cropped region disappears.

If the original asset carries C2PA provenance and a tool changes the content without creating an appropriate new provenance record, the previous content binding may no longer validate against the edited artifact. A provenance-aware workflow can instead describe the earlier asset as an ingredient and sign provenance for the new one.

An invisible watermark designed to tolerate cropping may remain detectable, within the limits of that watermarking system.

Burned-in subtitles create a different case. Most of the frames may look unchanged to a viewer, but the operation modifies those frames and commonly involves re-encoding. You cannot infer the provenance outcome from how small the visual edit seems.

A better production rule is simple:

Treat a transformed asset as a new verification point.

Screenshot and frame extraction create a new artifact

Screenshots make the distinction obvious.

Suppose an image contains ordinary metadata and an embedded C2PA Manifest Store. A screenshot reproduces the displayed pixels but creates another file. The original file-level structures do not automatically become part of it.

An in-content watermark may behave differently because its signal can still be represented in the captured pixels. Whether it remains detectable depends on the watermark and on how the screenshot was produced.

Extracting a frame from generated video has the same problem. The frame may preserve the visual content while leaving behind provenance that belonged to the original video asset or container.

A practical transformation matrix

No row here is a universal guarantee. The table shows where you need to test rather than assume.

Operation	Visible mark	File-level / C2PA provenance	Invisible in-content watermark	What your pipeline should do
Byte-preserving store/download	Remains	Embedded data should remain with the unchanged bytes	Should remain if the content is unchanged	Keep the original as a reference
Transcode	Usually remains visually unless composition changes	Do not assume preservation	Mechanism-dependent	Re-run provenance checks
Resize/reframe	May change or be cropped	Requires provenance-aware handling if a valid chain is needed	Mechanism-dependent	Verify the result
Crop	Can remove the mark	Existing binding may not validate against the edited asset without a new provenance step	May survive if designed for cropping	Verify the result
Overlay/subtitles	Usually remains underneath new content	New or updated provenance may be required	Mechanism-dependent	Treat as a new processed artifact
Screenshot/frame extraction	Visible pixels may carry over	Original embedded file structures do not automatically follow	Mechanism-dependent	Inspect the new artifact
Platform upload	Platform may inspect the incoming signal	Reading and preserving are different operations	Platform-dependent	Check ingest and downstream output separately

The answer repeats for a reason: verify again after processing.

A false yes/no table would be easier to scan and less useful in production.

Inspect the asset before and after you transform it

If provenance affects your publishing or compliance path, inspection belongs in the pipeline.

generate
   ↓
preserve original
   ↓
inspect / verify
   ↓
transform
   ↓
inspect / verify again
   ↓
publish

Keep the original artifact

Save a reference to the asset as it arrived from generation.

• What provenance did the generator originally provide?
• What provenance does the file we actually published contain?

You cannot reliably answer the first if the only retained copy has already been resized, recompressed, and edited.

Inspect ordinary media metadata separately

For video, ffprobe is useful for inspecting the container and streams:

ffprobe -v error -of json -show_format -show_streams input.mp4

That can expose format and stream information. It is not a universal C2PA validator, and it does not detect every proprietary invisible watermark.

The each::video probe capability performs the same class of ordinary media inspection by using ffprobe and returning its format and streams information as structured JSON.

{
  "model": "eachlabs-video-api",
  "input": {
    "capability": "probe",
    "input_url": "YOUR_INPUT_URL",
    "params": {}
  }
}

Useful media inspection, yes. A documented C2PA validator or invisible-watermark detector, no.

Validate signed provenance with a C2PA-aware validator

A Content Credential needs more than field inspection.

C2PA validation checks the manifest and its assertions, signatures, content bindings, and related credential information. The specification also distinguishes a manifest being valid from the signing credential being trusted by the validator.

A metadata viewer showing an “AI generated” string does not amount to successful C2PA validation.

Nor can you manufacture trustworthy provenance by copying a few metadata fields from the original into a transformed file. The signed provenance has to correspond to the asset and the history it declares.

Invisible watermarks need the appropriate detector

There is no universal detector for every invisible AI watermark.

A detector for one watermarking scheme does not automatically understand another. Some systems expose their own verification tools and are designed to remain detectable through common modifications; their robustness limits still differ.

The useful question is not “does this look like an AI image?”

“Is the provenance mechanism I expect actually detectable in this artifact?”

Repeat the check on the published candidate

Run the check on the final asset, not only the generator output.

original.mp4
→ crop
→ captions
→ transcode
→ final.mp4

The provenance state of original.mp4 is not proof of the provenance state of final.mp4.

Every media step can succeed. The video can look correct. The provenance can still have changed.

Reading a provenance signal is different from preserving it

Publishing platforms add another boundary.

A platform can inspect a file at upload time, use that information to decide what disclosure to show, process the media, and then serve other copies for playback.

platform receives asset
        ↓
platform reads signal
        ↓
platform decides whether to label
        ↓
platform processes asset
        ↓
platform serves new copies

These are separate events.

Platforms can use several signals

YouTube currently documents several ways an AI disclosure can appear: creator disclosure, use of its own generative tools, qualifying Content Credentials, and its internal systems. Its current “How this content was made” documentation says it can carry forward qualifying disclosures from secure C2PA 2.1-or-higher credentials indicating that the entire video was made with AI.

Meta likewise documents the use of industry-standard technical signals, including C2PA in relevant contexts, alongside disclosure and its own systems. For ads, its June 2026 update says it has begun rolling out automatic detection of ads created or edited with third-party AI tools through industry-standard signals.

That gives machine-readable provenance practical downstream value. A receiving platform may be able to act on a signal that arrives with the asset rather than relying entirely on a manually selected checkbox.

A label does not prove the credential survived downstream

Do not reverse the inference.

If a platform reads a Content Credential during ingestion and displays an AI label, you have learned something about the ingest path. You have not established that every re-encoded copy later served by the platform still carries the same credential.

Reading, labeling, processing, and preserving are different operations.

When downstream preservation matters, inspect the downstream artifact.

Provenance is not an ad-approval guarantee

Machine-readable provenance can support disclosure and labeling. Advertising-policy approval is a separate question.

Current platform material describes AI labeling as one transparency mechanism alongside other safeguards. It does not establish that correct provenance guarantees an advertisement will be accepted.

An asset can carry correct provenance and still violate an unrelated advertising or content policy.

Build for provenance loss, not provenance permanence

Do not make one portable signal carry the entire history of your asset.

generation record
├── prediction / trace ID
├── source model and revision, where available
├── generation timestamp
├── original output artifact
├── provenance checks performed
├── transformations applied
└── final published artifact

The exported file and this record serve different audiences.

Portable provenance helps systems receiving the asset. Your application record tells you what happened inside your own product even when a transformation changes what remains in the file.

Treat every transformed asset as something worth re-verifying

generation success
transcode success
upload success
video plays correctly
provenance missing

Nothing in the first four states guarantees the fifth.

Canberk Sinangil, Co-founder & CTO: “An unannounced provider upgrade is indistinguishable from a regression if you didn't ask for it.”

Provenance behavior belongs in the same operational category. If your production path depends on a particular watermark, credential, or output field, test that behavior against the model and output path you actually ship. Do not turn today's provider behavior into a permanent application assumption.

None of your code has to change for the assumption to become wrong. Model revisions, output routes, and provider behavior can change under a stable request schema.

So provenance checks belong in two places: after transformations you control, and around upstream changes you do not.

Where each::labs fits

each::labs sits across several stages of this path, but the documented boundary matters.

each::api can return prediction results containing generated media artifacts. each::storage can host files passed into later model and workflow stages. each::video can crop, scale, reframe, transcode, overlay, add visible watermarks, and perform other deterministic media operations.

Those capabilities let you build the media-processing path in one platform.

They do not, based on the current public documentation, amount to a universal C2PA validator or universal invisible-watermark detector. probe is media/container inspection. watermark is a rendered overlay.

That is an important distinction. Provenance behavior should be verified, not inferred from the existence of an orchestration layer.

If your application needs one direct model call followed by one export, adding a complicated processing graph solves nothing. If the asset does move through several stages, provenance becomes another property to check on the artifact users actually receive.

EU context: Article 50 of the EU AI Act applies from August 2, 2026. For the machine-readable marking and detection obligation in Article 50(2), the Commission describes a limited grace period until December 2, 2026 for qualifying AI systems placed on the market before August 2. December 2 is not the general start date for Article 50.

The legal rules raise the stakes. The engineering question stays the same: what information entered the workflow, and what information left it?

AI content provenance FAQ

Is an AI watermark the same as a Content Credential?

No.

An invisible watermark can be encoded into the image, video, or audio signal and detected with a compatible detector. A C2PA Content Credential represents signed provenance associated with an asset. Ordinary metadata is another layer.

One asset can carry more than one of them.

Can AI provenance survive resizing, compression, or transcoding?

Sometimes.

It depends on the provenance mechanism and the processing path. Some invisible watermarks are designed to remain detectable after transformations such as cropping or lossy compression. File-level and cryptographically bound provenance behaves differently when an application creates a modified or newly encoded artifact.

If the processed output matters, verify the processed output.

Does a missing AI watermark mean a file was made by a human?

No.

It means only that the signal you checked was not detected. The generator may not use that mechanism, that output path may not include it, processing may have changed or removed it, or you may not be using the required detector.

“No provenance signal found” and “human-made” are not equivalent conclusions.

Can a platform tell which model generated an image or video?

Sometimes, but not universally.

A Content Credential can carry source and claim-generator information a receiving system may know how to validate. An invisible watermark may identify content associated with a particular generation system. A platform can also have separate internal detection signals.

There is no universal model-identity field carried by every AI-generated image or video.

What should developers preserve when processing AI-generated media?

Keep the original output, maintain an application-side generation record, record the transformations applied, and verify portable provenance again after processing.

Do not make the final media file your only record of origin. If recipients need portable machine-readable provenance, do not make your private application database the only place that information exists either.

The useful production system keeps both.