C2PA in MP4 and MOV: Where the Credential Actually Lives

C2PA — the Coalition for Content Provenance and Authenticity — is the industry standard for signed content credentials. It is already well documented for images, and our explainer on what a C2PA credential is covers the general case. What surprises people is where the credential lives in a video file: not where you would expect.

If you are starting from scratch, the video metadata remover overview is the better entry point. This post is about the container layout.

It is not in moov

In a JPEG, C2PA lives in an APP11 marker segment among the other metadata segments. In video there is no such segment list, and the credential does not go into the moov metadata list where the TC260 label and the camera information live. It is a sibling of mdat.

The credential is stored in a uuid box. The uuid box is ISO's general extension point: a normal box with a fixed 16-byte extended type after the header, used to carry vendor- or specification-specific payloads. C2PA claims one specific UUID, and that UUID is the entire identification mechanism. If the sixteen bytes after the header are not that UUID, it is some other extension and it is left alone.

Concretely, a file carrying a C2PA credential has a uuid box sitting at the top level of the file, at the same level as ftyp, mdat and moov, carrying this extended type:

d8fec3d6 1b0e483c 92975828 877ec481

Producers write it into MP4, MOV and M4V alike. It is not tied to a particular vendor or a particular AI model — it is the standard credential, and the same UUID means the same thing in every container that supports it.

Why this placement is annoying to work with

Three practical consequences follow from the credential being outside moov.

It survives transcodes that would drop metadata lists. A transcode that rebuilds the moov box from scratch and copies mdat across carries the uuid box along with it, because the credential is not part of anything the transcode has reason to rebuild. Re-encoding your video to "clean it" is therefore a reliable way to end up still carrying the credential.

It is easy to miss with the wrong tool. Anything that walks the metadata list and reports what it finds will look at moov.udta.meta, find the TC260 label or the camera make, and confidently report that you have cleaned the file — while the C2PA credential sits untouched at the top level. If your file carries both, a list-walking cleaner silently leaves the credential in place.

It changes how you talk about verification. Because the credential is outside moov, a digest computed over moov alone will not change when only a C2PA box is removed. If a tool shows you a moov hash before and after and nothing moved, that does not mean the removal failed — it may mean the credential was outside what you hashed. Which is exactly why our verifier re-scans the whole file and reports remaining traces rather than relying on a digest.

Why removal means retyping, not deleting

Here is the interesting constraint. In a JPEG you can often drop a metadata segment and fix up the offsets, because the file structure is comparatively forgiving. In an ISO-BMFF container you cannot: every sample offset in the file is recorded in the moov box, in a chunk offset table. Removing eight bytes of media data would shift every frame in the file and invalidate the whole offset table.

So the credential cannot be physically removed. It can only be made ignorable. The approach is to rewrite the box's four-character type from uuid to free, and zero the body.

free is ISO's convention for a box that is present and correctly sized but carries nothing — a placeholder. A parser reading the file walks the top level, encounters a free box, and skips it. The box still occupies its original byte range, every offset after it is unchanged, and the credential is no longer presented as anything.

That is why removal preserves the file length exactly, and why the video metadata remover reports the same size before and after. It is not deleting a credential; it is retagging one so that nothing acts on it.

What removing it does and does not break

The honest framing: this breaks the chain of custody. A C2PA credential is a statement about content, and a consumer that trusts it would be relying on a manifest that now says free where it expected a credential. You cannot produce a valid credential that says "this was not AI-generated" without the signing key, and that is by design.

What you are left with is a file where the credential no longer appears, rather than a file carrying a fraudulent credential. If your goal is to make the assertion stop being made, that works. If your goal is to swap in a different assertion, that is a different tool entirely and it is not this one.

Checking for it yourself

If you want to know whether a file carries one, you do not need a video player. Dump the first few dozen boxes and look for a top-level uuid. Then compare the sixteen bytes following that box's header against the UUID above. If they match, you have found a C2PA credential; if they do not, it is some other extension and your file does not have one.

The video metadata remover does this for you along with the TC260 label in one pass, and tells you how many bytes each occupies before you decide to do anything. For the general C2PA background, including the image case and what removal means for signature validity, see how to remove C2PA.