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.
Three questions decide whether a free tool is worth opening, and they are the ones behind most of the searches that lead here: do I have to sign up, will it take my whole video, and does the file leave my machine.
| What people search for | What it usually means | Why it matters here |
|---|---|---|
| no sign up / without login | The work runs on your device instead of a server | A tool that needs an account has a reason to keep your file |
| full video / unlimited | No duration or size cap on the free tier | No server counts your seconds here — the ceiling is your own memory, and it is measured below |
| no watermark on the output | The tool does not stamp its own mark on the result | Adding a mark is a re-encode, and a re-encode touches every frame |
The third row is the one with a hard technical answer. If a tool adds its own mark to your file, it re-encoded that file, and there is no way to re-encode without touching every frame. This one adds nothing and re-encodes nothing: it walks the container's boxes and writes the bytes back, which is why the cleaned file is the same size as the original and the video inside it is unchanged.
Nothing is uploaded. The work runs in your browser against the file you dropped in, so there is no account to create, no queue to wait in, and no length limit imposed by somebody else's server.
That last claim is true in the sense people mean it and false in the sense they hope. Nothing on a server counts your megabytes, but the file still has to fit somewhere, and it fits in your machine's memory. This tool reads the file in, then builds the output as a full second copy so the original stays intact while the new one is written — which is why peak memory is about twice the file size, and why the ceiling belongs to your laptop rather than to a quota.
Measured on one 1080p H.264 file per size, in Chrome against a local copy of this page, timed from the click to the rendered report:
| File | Click to report | Peak memory | Memory per MB of file |
|---|---|---|---|
| 24 MB | 0.5 s | 85 MB | 3.5 MB |
| 90 MB | 1.6 s | 217 MB | 2.4 MB |
| 180 MB | 3.0 s | 398 MB | 2.2 MB |
End to end that is about 60 MB/s, and the memory settles at roughly twice the file once the fixed overhead of a browser tab is behind you. Two consequences are worth having before you drop a file in: a 400 MB phone video wants close to a gigabyte free, and when a large file appears to stall, closing a few tabs is the fix rather than reloading the page.
The wait is also not spent where you would guess. Splitting the 180 MB run into its four stages:
Finding the boxes costs 1.3 ms whether the file is 24 MB or 180 MB, because the tool reads the box tree at the front of the file rather than walking the media. Copying costs 66 ms. Reading the file in costs 78 ms. Comparing every byte of the output against the original costs 3,000 ms — 95% of the entire run, and forty-five times the copy it is checking.
That last number is worth arguing with, and it is deliberate. The comparison walks both buffers byte by byte, skipping only the regions that were freed, and it is the only reason the panel can state that the picture is unchanged instead of asking you to take its word. It is written for legibility rather than throughput. On a machine like this one the honest summary is: expect a second per hundred megabytes, expect memory at twice the file, and know that both numbers come from your own hardware rather than from a limit someone imposed on the free tier.
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 →
That is the honest boundary of this page. What a logo burned into the picture costs to hide, and which of the four ways of hiding it is worth its price, is measured separately on the logo page — including the pixel arithmetic for a crop and the one case where the picture underneath comes back.
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.
Nothing on the site imposes one, because nothing is uploaded and no server is counting your megabytes. The limit is your own free memory: the tool holds the original and a full copy of the output at the same time, so budget about twice the file size. Measured on a 4 GB machine with 1.2 GB free, a 180 MB file finished in 3.0 seconds and used 398 MB of memory. A 4 GB video would want roughly 8 GB free and will not fit on a machine like that one — a limit of the approach, not a paywall.
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.