A Sora watermark is two different things, and only one of them is in the file. The first is the mark you can see: the Sora glyph and wordmark drawn over the picture. On the export measured here — 704x1280, 300 frames, 10.1 seconds — it is about 132x46 pixels, and it is not fixed. It holds the top-left corner for 66 frames, appears at the lower right for 81, sits at the bottom left for 81, and returns to the top-left: three places, 2.2 to 2.7 seconds each. The second is the C2PA content credential, which is not a mark at all. It is a 14,358-byte uuid box at byte 32 of the file, immediately after ftyp and before moov, holding a signed record that names OpenAI.
The second one comes off, and the tool on this page takes it off. The first one cannot be removed without a re-encode, and the pixels it covered in a given frame are not in that frame any more. But because the mark moves, those pixels are in other frames of the same clip, and that is the only genuinely good news here — measured, bounded, and not a free lunch. Both halves are below, with the numbers.
This is the layer that comes off. It is a byte-level rewrite of the container: the uuid box carrying the credential is rewritten in place as a free box of exactly the same size with its payload zeroed, so nothing in the file changes position and the compressed video is never touched. Drop your file in and it lists what it found before it changes anything.
The phrase covers a record in the file and a drawing on the picture, and they have nothing to do with each other. Cleaning one does nothing to the other, which is why "did it work?" has two different answers depending on which one somebody meant.
| Layer | What it is | Measured on this export | Removable |
|---|---|---|---|
| The mark on the picture | The Sora glyph and wordmark, drawn over the frames as a translucent white overlay | About 132x46 px, in three places, 2.2–2.7 s each | No — not without a re-encode |
| The record in the file | A C2PA content credential: a signed JUMBF manifest naming OpenAI | A top-level uuid box, 14,358 B, starting at byte 32 | Yes — in place, no re-encode |
| The encoder tag | The ©too string inside moov/udta/meta/ilst | 37 B, reading Lavf60.16.100 | Yes — same rewrite |
Notice that the third row is not evidence about Sora at all. It says which piece of software last wrote the file, and on this export that was ffmpeg, not OpenAI — a useful reminder that a tag is a claim by whoever wrote it, not a fact about the content. The credential in the second row is different: it is signed, and it is the thing platforms and provenance tools actually read.
Most advice about removing a watermark assumes it sits still, so you draw one box over it and apply the same fix to every frame. That assumption is wrong here, and it is wrong in a way you can watch happen. Frame by frame, the mark's position on this clip is:
| Where the mark sits | Top-left corner of the mark | Frames | How long |
|---|---|---|---|
| Top-left corner | x 32, y 74 | 0–65 | 66 frames, 2.2 s |
| Lower right | x 546, y 596 | 66–146 | 81 frames, 2.7 s |
| Bottom left | x 32, y 1024 | 147–227 | 81 frames, 2.7 s |
| Top-left again | x 32, y 74 | 229–299 | 71 frames, 2.4 s |
Two consequences follow, and they pull in opposite directions. The first is bad news for anyone promising a one-click fix: a static box drawn once covers the mark for a third of the clip and misses it for the rest, and a tool that quietly blurs the whole bottom-left corner has damaged 71 frames to fix nothing. The second is the reason the picture layer is not hopeless. Because the mark keeps moving, the three rectangles it occupies never overlap, so every pixel it covers at any moment is visible, unmarked, in some other frame of the same clip.
That is the whole of the good news, and it comes with a bill. For a frame in the middle of one of those stretches, the nearest frame that shows the pixels underneath is 41 frames away — 1.4 seconds. Borrowing from there is exact if the shot is static and wrong if it is not, because in this clip the subject is moving and the background behind her is not the same 1.4 seconds later. The pixels exist; whether they belong is a different question, and the honest answer depends on the shot rather than on the tool.
The pages that rank highest for this term mostly do not repair pixels at all. Two of the top results I could read take a Sora share URL and hand back a clean MP4 in a few seconds, and one of them describes its output as the video "without the watermark overlay" — which suggests that the copy the player streams never had the mark burned into it, so there is nothing to remove. I could not verify that claim myself: sora.chatgpt.com refuses this machine, so it stays the tool's own description rather than my measurement.
Either way it is a different job from this page's, and it is one this site cannot do. Fetching a file from a link for you needs a server, and there is no server here — the whole point of the tool above is that your file never leaves your machine. So: if you have a share link, one of those tools is the right instrument and this page is the wrong one. If you have the file already downloaded, they cannot help you at all, and that is who this page is written for.
These are the numbers for the picture layer, and they come from a different experiment than the schedule above, because this one needs something a real clip cannot give you: a clean copy to compare against. A 640x360 clip with a 100x40 mark was built twice, once with the background still and once with it travelling 284 pixels behind the mark, and each method was scored against the clean original over the mark's own rectangle.
| What you do | Region score, background still | Region score, background moving 284 px | What it costs |
|---|---|---|---|
| Do nothing — the mark stays | 4.33 dB | 4.07 dB | — |
Hide it — delogo, interpolated from the ring around it | 26.70 dB | 27.55 dB | a re-encode of every frame |
| Hide it — blur, smeared | 6.20 dB | 5.82 dB | a re-encode, and an obvious patch |
| Crop it off — deleted with the band it sits in | no score to give: the pixels are gone | 6.4x the mark's area, and the aspect ratio changes | |
| Carry it back from other frames — real pixels | impossible | 51.33 dB | a re-encode, and the mark has to move |
Read the last row together with the schedule above and you have the situation for Sora exactly. On a clip where the mark is fixed, carrying pixels back is impossible — there is no other frame that shows them. Sora's mark moves, so the condition is satisfied by the mark's own travel rather than by the camera, and the pixels are genuinely there to be borrowed. What you are borrowing is a moment: up to 1.4 seconds away, from a shot that has moved on. Where the background is flat or still, that is as good as a clean copy. Where it is not, you have swapped a visible mark for a small patch of the wrong moment, and no tool can decide that trade for you. The full measurement of each method, including the hybrid that borrows where it can and interpolates where it cannot →
Three limits, stated plainly, because a page about watermark removal that only lists what works is a sales page.
It cannot take the mark off the picture in your browser. Tracking a mark that changes place every two seconds and rebuilding what was underneath it needs a video pipeline. The tool above is honest about this: it lists the container records it finds and rewrites them, and it will tell you when the mark is in the pixels instead.
It cannot take a share link. No backend, so no fetching on your behalf. See the section above for which tool to use instead.
It cannot tell you the video is now untraceable. The credential is gone and cannot be checked, but the picture layer leaves a repair behind, and a repair that borrows from a different moment is a different kind of evidence. Removing a mark is not the same as making the file indistinguishable from an unmarked one, whatever a tool's marketing says.
Every number on this page came out of a command. The box list, which is what shows whether a credential was ever there:
python dev/video_meta_report.py yourfile.mp4
The tool's claims, on your own file — it prints the inspect report, the rewrite report, and refuses if a claim fails:
node dev/sora-test/run_cleaner.js yourfile.mp4 cleaned.mp4
And that the output still decodes, which is the check that matters after any container edit:
ffmpeg -v error -i cleaned.mp4 -f null -
The scripts behind this page are dev/sora-test/run_cleaner.js, dev/sora-test/track_mark.js and dev/video_motion_recovery.py, and the tool itself is tested by _selftest/video.js. What an MP4 keeps besides the picture, box by box →
Half of it, and which half is not a matter of opinion. The C2PA content credential is a box in the file, and this page's tool removes it in the browser, verified on a real Sora export. The mark you can see is drawn over the picture, so it cannot be removed without re-encoding, and the pixels it covered in that frame are not in that frame any more. What the mark moving does give you is a source of real pixels from other frames, and that is measured further down this page.
It moves. On the export measured here, a 10.1-second 704x1280 clip at 30 frames per second, the mark sits in the top-left corner for frames 0 to 65, at the lower right for frames 66 to 146, at the bottom left for frames 147 to 227, and back in the top-left corner for frames 229 to 299. That is three distinct places, each held for 66 to 81 frames, or 2.2 to 2.7 seconds. This matters because a tool that asks you to draw one box around the mark once will be wrong for most of the clip.
Because fetching a file from a link is a different and much easier job than repairing pixels. Two of the top-ranking pages for this term take a Sora share URL and return a clean MP4; one of them describes its output as the video without the watermark overlay, which suggests the copy the player streams never had the mark burned in. I could not confirm that myself, because sora.chatgpt.com refuses this machine, so it stays their description rather than my measurement. Either way it needs a server, which this site does not have, and it cannot help anyone who already has the file.
Sometimes, and not in a way you can rely on. The credential is a top-level uuid box, and encoders differ on whether they carry unknown top-level boxes through. The honest answer is that you should check the output rather than assume: the box list is one command away, and this tool's whole design is to make the outcome checkable instead of guessed. Note also that a re-encode is what destroys the picture, so it is a strange way to remove a record that can be dropped without touching a single frame.
Removing the file layer does not, and that is measured rather than asserted. On the Sora export used here the output is the same 5,321,234 bytes, every byte outside the rewritten regions is identical, the compressed video payload is byte-for-byte identical at 5,294,792 bytes, and the result still decodes all 300 frames. Removing the picture layer is a re-encode by definition, so the file plays but the picture has been through a decoder and an encoder.
They cannot check the credential, because it is gone, and that is the point of removing it. What they can still see is whatever the repair left behind: a region that has been interpolated from its surroundings, or pixels borrowed from a moment up to 1.4 seconds away that do not match what the shot was doing. The metadata layer is a clean removal; the picture layer is a repair, and repairs have a visible cost. Anyone telling you a pixel-level removal leaves no trace is describing the first layer and selling you the second.
The file layer, yes, and it is the only way it works here. Rewriting a box is byte arithmetic on the container, so it needs no decoder, no encoder and no server, and the file never leaves your machine. The picture layer cannot be done in a browser tab at all: tracking a mark that changes position every two seconds and rebuilding what was under it needs a video pipeline, which is why the recipe on this page is a local command rather than a button.