This tool removes the provenance and metadata layer from an MP4 or MOV — the C2PA box and the descriptive tags — and it does it without touching a single frame. It cannot remove a watermark that is burned into the picture. Neither can any other free remover: the pixels can only be changed by re-encoding, which alters every frame and still does not restore what was underneath the mark. So the split is honest and simple. If what you want gone is a record attached to the file, this removes it and shows you the proof. If what you want gone is a logo you can see, no lossless tool can help you, and the ones claiming otherwise are re-encoding your video.
Everything below the tool is measured on this machine, and the test suite that produces the numbers is in the repository.
An MP4 is a list of boxes. The picture lives in one of them and the records about the file live in others, which is why this separation is possible at all.
| Box | What it holds | This tool |
|---|---|---|
uuid | The C2PA content credential — who or what made the file, and what was done to it | Rewritten as padding. The identifier no longer appears anywhere in the file |
moov/udta/meta/ilst | Title, artist, comment, and the encoder string that names the software that wrote the file | Each tag rewritten as padding |
moov/udta/(c)xyz | Location — GPS coordinates, in the QuickTime style | Rewritten as padding |
mdat | Every frame of video and every sample of audio | Never read, never written. Byte-identical afterwards |
moov, trak, stbl, stco | The index the player uses to find each sample in mdat | Left exactly where it is, so every offset stays valid |
Three things are deliberately left in place even though they are metadata, and each has a reason. The ftyp brand says which specification the file follows, and a player needs it. The per-track handler_name and vendor id sit inside a box the player also needs, so removing them would mean rewriting that box rather than removing it. And the compressor name — the string that names the encoding software — is not a box at all: it is a fixed 32-byte field inside the sample entry, next to the frame width and height, so clearing it means editing a structure whose header length depends on the track type. This version does not do that, and says so rather than quietly claiming a cleaner file than it delivers. The full box-by-box account →
Every other approach to this problem removes the box and lets the rest of the file shuffle up. That is the obvious thing to do, and on some files it destroys them. The reason is the chunk offset table.
A player does not scan a video file to find the frames. It reads stco inside moov, which is a list of absolute byte positions saying "sample one starts at offset 40, sample two at offset 4,891". Those numbers are positions in the file itself. Delete a box that sits before mdat and every sample moves while the table stays the same — so the decoder starts reading frames from the wrong bytes.
This is not hypothetical, and it is worth stating as a measurement rather than a warning. Inserting the C2PA box where the format puts it — right after ftyp, before moov — shifts the media by 158 bytes. On a test file where that table was left alone:
box inserted, offset table not corrected 0 of 72 frames decode same insertion, offset table corrected 72 of 72 frames decode
Zero frames. Not a subtle artefact — a file that no longer plays. So this tool takes the other route: it rewrites the offending box in place as a free box of the same length, with its payload zeroed to noughts. The record is genuinely destroyed, the box type no longer claims to be a credential, and no byte anywhere in the file changes position. That is also why the file does not get smaller, and why that is the right trade.
Do not take the panel's word for it. The output file is yours, and one command reads it back:
ffprobe -v error -show_format -show_streams cleaned.mp4
Before cleaning, a file with tags reports them under TAG: lines. After cleaning those lines are gone, and the codec, resolution and duration are unchanged. If you want the stronger check, compare every decoded frame:
ffmpeg -i original.mp4 -f framemd5 - > before.txt ffmpeg -i cleaned.mp4 -f framemd5 - > after.txt diff before.txt after.txt
No output from diff means every frame decodes to identical bytes. That is the check this site's own test suite runs, across seven fixtures including a faststart file where the C2PA box sits before the media. The three layers a video watermark can live in →
Search for a free video watermark remover and you will find dozens, and almost all of them will ask you to upload your file. That upload is the tell: the work they do needs a server because they are re-encoding, and re-encoding a video takes a decoder and an encoder, which is a lot of machinery to ship to a browser. The output is a second-generation file — slightly softer everywhere, larger or smaller depending on settings, and still carrying the mark if the mark was painted across the picture rather than sitting in one corner.
The one operation that genuinely needs no re-encoding is the one this page does: editing the container. It is also the only one that can promise the picture is untouched, because it never touches it. The same split on the image side →
Not without changing the picture, and that is true of every free tool including the ones that do not say so. A visible watermark is painted into the frames, so the only way to remove it is to re-encode the video around it — which alters every frame, not just the marked one. Measured on this machine, covering the mark with ffmpeg's delogo filter improves the picture from 23.55 dB to 33.63 dB against an unmarked render, which is an improvement and not a restoration: the mark's rectangle becomes an interpolated patch. A tool that offers to remove a visible watermark for free is re-encoding your video.
No, because the metadata is not part of the picture. In an MP4 the video lives in the mdat box and the metadata lives in separate boxes beside it. This tool rewrites those other boxes and never reads mdat, so the compressed video data is byte-for-byte identical afterwards. The test suite checks that: every frame decodes to the same MD5 before and after.
Because removing bytes would move everything after them, and that breaks video files. The chunk offset table in the moov box stores absolute file positions into mdat; shift mdat and every one of those offsets is wrong. So instead of deleting a box, this tool rewrites it in place as a free box of exactly the same size with its payload zeroed. The metadata is genuinely gone, and not one byte in the file changes position. On a test file where the same box was inserted without correcting that table, zero of 72 frames decoded.
If the file is an MP4 or MOV, yes — which covers what iPhones, Android phones and most screen recorders produce. Those files carry the same boxes: a moov with a user-data area, and often a creation-time and location field. If the first box in the file is not ftyp, it is not this kind of container and the tool will say so rather than guess.
For the layer this tool touches, treat it as ordinary editing: descriptive tags and a provenance record are not copyright notices, and removing them from a file you own is no different from retyping a paragraph. Where it stops being ordinary is when you are stripping someone else's attribution to pass their work off as yours, or when a platform's terms or a contract require the credential to stay. This is not legal advice; if the stakes are real, ask someone qualified.
No. The file is read into memory by your own browser, edited there, and offered back as a download. There is no backend that could receive it. You can confirm that in about fifteen seconds: open DevTools, switch to the Network tab, clean a file, and count the requests. Nothing in this tool opens a connection.