Six jurisdictions and four US states now require AI-generated media to carry a machine-readable mark inside the file, so we generated images, video and speech through 16 API SKUs (individually priced model variants) and read the bytes that came back: 7 carry a C2PA manifest, 4 carry China's implicit label, none carry both, and the video and audio SKUs carry nothing. Then we put the marked files through ordinary image processing, and every C2PA manifest died on the first re-encode, resize or crop in both imaging libraries we tried. This post measures exactly where the gaps are and what closing them costs.
TL;DR
- 7 of 11 image SKUs embed C2PA (OpenAI, ByteDance); 4 embed China's implicit label (Alibaba); zero embed both.
- The video SKU and all 4 speech SKUs returned files with no marking at all, though EU and California rules cover both.
- OpenAI's signature validates against the official C2PA trust list; ByteDance's is valid but untrusted, chaining to a root the list does not carry.
- No C2PA manifest survived any transform; China's label survives PNG-to-PNG work in ImageMagick, not in Pillow, and neither survives a format change.
Which rules actually require something inside the file?
Far fewer than the volume of AI legislation suggests. Most AI-content laws ask for a label a human can see, or for takedown when synthetic media causes harm; the ones below reach into the bytes, and those are what an API user has to satisfy at generation time. This is an engineering reading of the cited texts, not legal analysis; for the legal side, the Commission's Article 50 guidelines and the IAPP global AI law tracker are the places to start.
| Regime | What the file must carry | Since |
|---|---|---|
| EU AI Act Art. 50(2) | marking "in a machine-readable format"; names no technique, and the Code of Practice is technology-neutral too | 2026-08-02 |
| China's labelling measures + GB 45438-2025 | an implicit label in metadata with prescribed fields (producer code, content ID, signature) plus a visible label; the only regime with its own schema and the only one already enforcing | 2025-09-01 |
| India, IT Rules G.S.R. 120(E) | a visible label and "permanent metadata or other appropriate technical provenance mechanisms ... including a unique identifier" | 2026-02-20 |
| Vietnam, AI Law Art. 11(2) | audio, image and video "marked in machine-readable format"; the technique is undefined | 2026-03-01 |
| Kazakhstan, AI Law Art. 21(2) | machine-readable marking plus a visible warning for content simulating a person or event | 2026-01-18 |
| South Korea, AI Framework Act Art. 31 | human-perceptible or machine-readable, operator's choice; grace period into 2027 | 2026-01-22 |
| US: California, then Connecticut, Utah, Washington | a "latent disclosure" carried in the file: provider, system name and version, time and date, unique identifier; California also wants a free public detection tool. Providers with over a million monthly users | 2026-08-02 to 2027 |
Everyone else asks for a label a human can see, or nothing: more than thirty US states require a disclaimer on election deepfakes, and there is no general marking mandate in US federal law, the UK, Japan, Australia or Singapore. (Two traps: Norway is not yet covered by Article 50, since the AI Act is not in the EEA Agreement, and Italy's 2025 AI law contains no marking duty despite wide reports otherwise.)
Three engineering facts follow. The regimes are specified in incompatible ways: the EU names no format, China prescribes its own schema, India and Vietnam demand provenance without saying which kind. C2PA, the format most Western vendors ship, is named in binding law almost nowhere: only Connecticut and Washington name it, and no national regime does. And five legislatures wrote durability into the duty, asking for provenance "difficult to tamper with, remove or disassociate" (Connecticut), "difficult to remove or tamper with" (Washington), "permanent metadata" (India), "tamper-evident" (Utah's election-ad law) or "permanent or unable to be easily removed" (Colorado's). The transform tests below measure how well the available technology delivers on those phrases.
What is a C2PA mark, physically?
A block of signed JSON added to the file, invisible in the picture itself. C2PA, from the Coalition for Content Provenance and Authenticity, defines a "manifest" in its technical specification: a record of who made an asset and how, cryptographically signed so tampering is detectable. In a PNG it rides in its own chunk alongside the pixels, and walking the chunks of one of our generated images shows exactly where it sits and what it costs:
IHDR 13 bytes image header
caBX 21,767 bytes C2PA manifest store <- the mark
IDAT 2,115,575 bytes the actual pixels
IEND 0 bytes
About 22 KB on a 2 MB image, roughly 1%, and no pixel changes: nothing is drawn on the image, so it looks identical in any viewer, and a "Content Credentials" badge appears only in software that looks for one.
Inside, the manifest a verifier reads from an OpenAI image looks like this, trimmed to the load-bearing fields:
{
"claim_generator_info": [{ "name": "OpenAI Media Service API" }],
"signature_info": {
"issuer": "OpenAI OpCo, LLC",
"time": "2026-08-22T13:47:29Z"
},
"assertions": [{
"label": "c2pa.actions.v2",
"data": { "actions": [{
"action": "c2pa.created",
"when": "2026-08-22T00:00:00Z",
"softwareAgent": { "name": "gpt-image", "version": "pre-2.0" },
"digitalSourceType": ".../digitalsourcetype/trainedAlgorithmicMedia"
}]}
}]
}
Three parts do the work. The action says the asset was created rather than edited, and digitalSourceType: trainedAlgorithmicMedia is the IPTC vocabulary term for "made by a generative model", the field that actually says "AI" in machine-readable form. The software agent names the model. The signature binds it all to a certificate, so a verifier can tell whether the claim was altered and who stands behind it.
China's implicit label, defined by GB 45438-2025, the mandatory national standard published alongside the labelling measures, solves the same problem with no signing authority at all. It is a plain text chunk of JSON:
{ "Label": "1",
"ContentProducer": "001191330106MA2CFLDG4R10001",
"ProduceID": "U-9TlH0PCIQomj9MzIc5VUuQ",
"ReservedCode1": "K-LBkc9peJ0Gox..." }
Label: 1 means AI-generated, ContentProducer is the provider's registered company code, ProduceID the vendor's content number, and ReservedCode a signature value. Same goal, different trust model: C2PA asks a certificate authority to vouch for the claim; the Chinese label points at a registered company and leaves verification to whoever wants to check.
What do the APIs actually embed?
Seven of eleven image SKUs embed C2PA, four embed the Chinese label, and the split runs strictly along vendor lines:
| SKU | Format | C2PA | China implicit label | Creation timestamp |
|---|---|---|---|---|
| gpt-image-1, 1-mini, 1.5, 2 | PNG | yes | no | date only, 00:00:00Z
|
| seedream-4.0, 4.5, 5.0 | JPEG | yes | no | precise to the second |
| qwen-image-2.0, 2.0-pro | PNG | no | yes | none |
| wan2.7-image, 2.7-pro | PNG | no | yes | none |
| seedance-1.5-pro (video) | MP4 | no | no | n/a |
| tts-1, qwen3-tts, google-tts-standard, chirp3-hd | MP3 / WAV | no | no | n/a |
Both C2PA camps assert exactly the fields shown above, c2pa.created plus trainedAlgorithmicMedia, and both Chinese-label vendors emit the same GB 45438 structure, with one addition: a second pair of fields naming whoever redistributes the file. Three details matter more than the yes/no columns.
The signatures are not equally trusted. Verification has two steps: read the manifest, then check whether its signing certificate chains to a root on the C2PA trust list. A stock verifier trusts nothing out of the box and reports signingCredential.untrusted for every file, good ones included, so loading the official list is the first job for anyone verifying at scale. With it loaded, OpenAI's images come back trusted, their issuing CA being one of the 17 entities on the list. ByteDance's do not: their manifests are signed under a GlobalSign S/MIME intermediate, a certificate type meant for email, whose root the list does not carry. In the specification's terms the ByteDance manifests are valid (signature checks out, image unaltered since signing) but not trusted, so a conforming verifier will not vouch for who made the claim.
OpenAI's timestamp carries no time. Every OpenAI manifest said 2026-08-22T00:00:00Z, midnight of the generation date, while ByteDance recorded the actual second. Coarsening is a defensible privacy choice, but California's latent disclosure asks for "time and date", and a date-only value is worth raising with counsel.
Audio and video are empty. The AI Act and California both cover synthetic audio and video, and this is not a format limitation, since the C2PA specification supports MP4, WAV and MP3 as carriers. The MP4 we generated carried standard QuickTime container fields and nothing else; the four speech files carried only codec headers. The marks were also identical whether images came back as base64 or by URL, so nothing on the delivery path adds or strips provenance.
Do the marks survive normal handling?
The C2PA manifest never survives, and the Chinese label survives only if your imaging tool carries text chunks. That distinction appeared because we ran the same five operations twice, through Python's Pillow and through ImageMagick, on three marked files: an OpenAI C2PA image, a ByteDance C2PA image and an Alibaba Chinese-label image.
| Transform | C2PA (OpenAI) | C2PA (ByteDance) | China label (Alibaba) |
|---|---|---|---|
| Byte copy | survives | survives | survives |
| Re-encode to PNG | gone | gone | tool-dependent |
| Resize to 50% | gone | gone | tool-dependent |
| Crop 10% | gone | gone | tool-dependent |
| Convert to JPEG q90 | gone | gone | gone |
| Convert to WebP q85 | gone | gone | gone |
Pillow lost every mark on every operation, 0 of 15. ImageMagick kept 3 of 15, all three being the Chinese label surviving a PNG-to-PNG operation. Image quality is not the mechanism: re-encoding to lossless PNG destroys a C2PA manifest as thoroughly as a lossy JPEG does.
The asymmetry has a simple cause. China's label is an ordinary PNG text chunk (tEXt, the standard slot for key-value strings), so a tool that copies text chunks carries it for free, which ImageMagick does by default and Pillow does only if you ask. The C2PA manifest lives in a custom chunk that mainstream imaging tools do not know about, so they drop it whether or not you ask them to keep metadata: ImageMagick discarded it on a plain resize, and again when we passed the flag that explicitly includes every chunk. Both marks die at a format boundary, because a PNG text chunk has nowhere to go in a JPEG or WebP.
So the practical rule is more specific than "metadata is fragile". If you must transform, stay inside one format and pick a library that carries text chunks, and the Chinese label rides along. For C2PA there is no preservation path in ordinary tooling: the supported move is to re-sign after the transform, which works but changes the claim, since the new manifest names your pipeline as signer rather than the model vendor and reads as untrusted until your certificate is on a trust list.
Set that against the five statutory phrases above. A thumbnailer, a CDN transform, an EXIF-stripping privacy step or a user's screenshot all erase these marks, so the technology those laws point at cannot, on its own, deliver the durability they ask for. The layer that does survive is an imperceptible watermark painted into the pixels, and Google's SynthID, the most widely deployed, has no public detector and a waitlist-only checking portal, so a third party cannot confirm one is present. What is verifiable from the file is the metadata layer, and across two libraries and three marks it survived a transform in exactly one pairing: ImageMagick with the Chinese label.
If the mark dies anyway, is it worth shipping?
Yes, because the platforms that matter read it at the one moment it still exists: upload. A manifest that will not survive your thumbnailer is still read when you hand over the original file, and the label the platform attaches to the post outlives the metadata entirely.
| Platform | What it reads on upload | What happens |
|---|---|---|
| TikTok | C2PA Content Credentials, since May 2024 | auto-labels AI content made elsewhere; also attaches its own credentials to TikTok content, which "remain on content when downloaded" |
| YouTube | C2PA metadata, plus creator self-declaration | "Content that contains C2PA metadata" is labelled automatically; creators who consistently fail to disclose face label enforcement, removal, or suspension from the Partner Program |
| Meta | C2PA and IPTC indicators, plus classifiers and self-disclosure | applies an "AI info" label |
| C2PA manifests only, no detector of its own | shows a Content Credentials badge | |
| X | no provenance reading documented in its authenticity policy | classifier and report-driven enforcement |
That changes the engineering conclusion. The metadata layer is not a durable property of your file, it is a one-time signal you get to send to whoever receives the original bytes. Ship it, and TikTok and YouTube convert it into a label that lives in their database rather than in your PNG. Skip it, and you are relying on their classifiers to guess. Two limits: none of these platforms documents whether the file it serves back still carries the manifest, and we did not test that; and X documents no provenance reading at all.
What do you do when the file arrives unmarked?
You add the mark yourself, and the real question is which layer you can add and where. We measured the metadata path: signing an unmarked Alibaba image with our own C2PA manifest took 59 ms and grew the file by about 8%, from 1.18 MB to 1.28 MB. The new manifest declared c2pa.created with trainedAlgorithmicMedia, named the upstream model, and coexisted with the Chinese label already in the file, so a file can carry both systems even though no vendor ships both. Two caveats: our self-signed manifest reports as untrusted for the same reason ByteDance's does, and re-encoding the signed file destroyed the new mark exactly as fast as the vendor's.
| Fix | What it addresses | Cost | Fragility |
|---|---|---|---|
| Sign a C2PA manifest offline, after generation | EU machine-readable marking; California's latent disclosure if you populate provider, version, time and an identifier | 59 ms, +8% size, plus a certificate from a recognised issuer | dies on any re-encode |
| Inject the manifest at delivery time, in the API path | same as above, applied uniformly | same operation, moved earlier | same |
| Burn a visible label into the pixels | California's on-screen option (the statute calls it a "manifest" disclosure, unrelated to a C2PA manifest), China's explicit label | one compositing step | survives everything, changes the image |
| Keep a generation log keyed by content hash | evidence of compliance, China's six-month retention duty | storage, no per-file work | independent of the file |
| Imperceptible watermark | the layer that survives transforms | open-source encoders exist, but no interoperable standard, so nobody else can verify yours | n/a |
Signing offline versus signing in the API path is the same operation on the same bytes; the difference is who the signature names. Signing at the gateway makes the gateway the entity attesting to the file's origin, while signing in your application makes you that entity, with your own certificate and key custody. If your obligation is to disclose that your product generated something with AI, the attestation belongs where that obligation sits.
One control needs no file surgery, and it is the one teams overlook: a generation log. China requires providers who hand over content without a visible label, which is what every API does, to keep records of who received it for at least six months, and a log is also how you evidence compliance once the file has been through a pipeline. If you already log request IDs, models and timestamps, what is usually missing is a hash of the delivered bytes, so an entry can be matched back to a file that has since lost its metadata.
FAQ
Do Chinese image models mark their output?
They mark it, but not with C2PA. Alibaba's qwen-image and wan2.7 SKUs embed the implicit label defined by GB 45438-2025: a metadata field carrying the producer's registered company code, a content ID and a signature value. ByteDance's seedream SKUs do the opposite, embedding C2PA and no Chinese label. Across 11 image SKUs, none embedded both.
Will a C2PA mark survive if my pipeline resizes the image?
No, not through mainstream imaging tools: a resize in Pillow or ImageMagick drops the C2PA manifest. The manifest lives in a custom chunk that Pillow and ImageMagick both discard, even when asked to include every chunk, so the only supported route is to re-sign the transformed file, which makes your pipeline the signer. China's label is an ordinary PNG text chunk that ImageMagick carries by default and Pillow carries if you copy it; both lose it on conversion to JPEG or WebP.
Is an unmarked API output a compliance problem for me?
Whether an unmarked file is your problem depends on whether you are a provider or a deployer under your regime, which is a question for counsel. What the measurements settle is the factual half: if you generate speech or video through these APIs, or images through the Alibaba SKUs for an EU audience, the file carries nothing a European verifier will recognise, and adding a mark is your work.
Measured 2026-08-22 through the Synthorai gateway: 11 image SKUs generated twice each and delivered as base64 and by URL, one video SKU and four text-to-speech SKUs, every file inspected for C2PA manifests, IPTC and XMP fields and GB 45438 label chunks. C2PA signatures were validated with the official trust list loaded, and against the interim list used by the public Content Credentials verifier. Survival tests ran five operations (PNG re-encode, resize, crop, JPEG and WebP conversion) over one marked file per family through both Pillow and ImageMagick, including each library's metadata-preserving options. Remediation figures come from signing an unmarked image with our own manifest and re-inspecting it before and after transformation. Regulatory rows are engineering readings of the cited texts, not legal advice; vendors change marking behaviour without notice, so re-measure before relying on any row.
Related, same series: what image generation costs, Qwen-Image 3.0 measured, video generation pricing, voice agent costs.
Top comments (0)