Which APIs Mark AI Content? 16 Measured Against 10 Marking Laws

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.

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:

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.

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.

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.

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.