How to Remove AI Metadata from a Video (Without Re-Encoding)

Removing AI metadata from a video sounds like it should be simple and in practice it usually goes wrong, because most approaches re-encode the file. This post is the byte-level version: what is in the file, what gets overwritten, and how to confirm you actually got it. If you want the background on why any of this exists, start with the video metadata remover overview.

Before you start: know what "remove" means here

There are three different layers people conflate, and only one of them is what this covers.

The first is visible marking — a watermark burned into the pixels. No metadata tool touches it, because the information is in the image data and removing it means re-encoding. See AI video watermark for that layer.

The second is metadata: a TC260 AIGC label, a C2PA credential, the encoder string. This lives in the container's box tree, in boxes with declared sizes, and is what you are removing here.

The third is statistical or signal-level marking, where a pattern is embedded subtly in the frames themselves and needs a detector rather than a parser. Also out of scope.

Everything below is about the second layer.

Step one: check what the file carries

Drop the file in and read the report before you change anything. A report worth trusting tells you four things: what kind of trace it found, which box path it lives at, how many bytes it occupies, and — for a TC260 label — which producer wrote it.

This step matters because the two trace types live in completely different places, and a cleaner that only understands one of them will give you a false all-clear. C2PA in video covers that in detail; the short version is that a TC260 label is inside moov.udta.meta, while a C2PA credential is a top-level uuid box sitting beside mdat.

It also matters because a lot of files carry nothing. If the report comes back empty, there is no work to do, and you have just avoided an unnecessary re-encode.

Step two: overwrite rather than delete

This is the core of the technique, and it is worth understanding even if you never write the code yourself.

An MP4 records the location of every frame in a chunk offset table inside the moov box. If you physically delete bytes from the file, everything after the deletion point shifts by however many bytes went away, and every one of those recorded offsets is now wrong. You would have to rewrite the offset table — and if the file is chunked, that means recomputing a potentially enormous number of entries.

You do not have to do any of that. Because the metadata sits in its own boxes with declared sizes, you can overwrite the contents and leave every size field alone. Nothing moves. Every offset stays correct. The file plays exactly as it did.

So removal is implemented as an overwrite of specific byte ranges:

A TC260 label is text, so its bytes are replaced with spaces. Two ranges get blanked — the AIGC name in the key table, and the label document itself. They are not adjacent, so blanking them as two separate spans rather than one range matters: a single range covering both would swallow the entries sitting between them, which are the encoder and brand strings that are none of our business.

A C2PA credential is a box, so it is handled differently. Its four-character type is rewritten from uuid to free, and its body is zeroed. Retyping to free is what makes a parser skip it — free is ISO's placeholder for a correctly-sized box that carries nothing. The box stays in the file occupying its original range, so no offsets move, but nothing acts on the credential any more.

Neither of these is forgery. The first produces text with spaces in it. The second produces a placeholder box. Neither is a valid credential asserting something different.

Step three: confirm the file still reads

This is the step that separates a tool you can trust from one you cannot, and it is the one most tools skip.

After overwriting, re-run the scan on the output. If the output no longer parses as a container at all, or if any trace survives, the tool must report a failure rather than hand you a download. An overwrite that ran past a box boundary would leave you with a corrupt file, and finding that out after you have already replaced your original is much worse than being told the operation failed.

We re-scan on purpose rather than assuming the writes landed, because "I wrote the bytes I intended to write" and "the file is still valid and clean" are different claims.

Step four: know what your proof actually proves

If you want evidence beyond "the tool said so", a digest is useful — but be precise about what it covers.

A hash over the moov box is a good fingerprint: every TC260 label lives inside moov, so removing one changes that digest, and you can prove the metadata segment was rewritten. It is fast because moov is small even in a large file.

It is not a whole-file checksum, for the obvious reason that hashing a gigabyte in a browser is slow. And because a C2PA credential sits outside moov, removing only a C2PA credential leaves that digest unchanged. That is not a bug in the hash — it is information about where the credential lives.

So the honest division of labour is: the rescan proves nothing is left, and the digest proves the metadata segment changed. Neither alone is a complete answer, and a tool that presents only one as "verified" is overstating it.

What does not change

Worth stating plainly, because these are the properties people care about: your file keeps exactly the same length. Your video and audio bytes are byte-identical to the original — the media payload is copied through untouched. No frame is decoded, so there is no generational quality loss. And nothing is uploaded; the whole thing runs in the browser.

That last point is what makes a large file practical. Reading in 4 MB chunks means peak memory tracks the chunk, not the file, so a 1 GB clip costs about what a 2 MB one does.

If you want to try it, the video metadata remover takes 3 videos a day without an account, or 5 with one, and runs entirely on your device. For what the label itself contains, see the TC260 AIGC label field guide.