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.
Sora is the best-documented case, not the only one. Every generator that marks its output does it in the same two places, so the layer test transfers directly — and it is worth being explicit about which layer each name belongs to, because the searches mix them up constantly.
| What you are looking at | Layer | Comes off? |
|---|---|---|
| A logo or a name painted onto the frames | Pixels | No — crop it, cover it, or re-encode, each at a cost |
| A provenance record in the container | Container | Yes, losslessly, video bytes untouched |
So when a search says "remove Veo watermark" or "Kling AI video watermark remover", the answer depends entirely on which of those two rows the mark is in, and the test is the same one used on this page: strip the container and look again. If the mark is still on screen, it was paint. Nothing about the generator's name changes that.
What does differ between generators is whether the visible mark moves. A fixed corner logo can be covered with a single rectangle. A mark that travels cannot, and that is measurable rather than a matter of opinion — on this site's test clip a travelling mark was still on screen in 63 of 72 frames after a fixed box was placed over where it started. If the mark in your file animates, budget for frame-by-frame tracking in a real editor instead of a one-click fix, and remember that a tracked patch is still a reconstruction.
One caution that applies across all of them: tools offering to remove a named generator's mark by asking for a share link are asking you to hand over content that may not be yours, and most of them are guessing. Knowing the model's name does not give a website any power over pixels that were already overwritten. The four options for a logo and what each costs →
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.
No, and the people asking are the evidence rather than the argument. A thread in r/OpenAI titled "Sora 2 Pro still has WATERMARK??", posted 17 January 2026, is the clearest single example. Quoted as written:
"Just bought the Pro version of CHATGPT which allows for Sora 2 Pro usage. I'm surprised to discover you still get the same frigging watermark on the video!! even after paying 200$? surely this is a glitch… Atleast I hope it is."
Two replies in that thread, also as written. One: "it will always be watermarked via the consumer app. you have to use the api if you want it without." Another, explaining the confusion: "No watermarks was a Pro feature in Sora 1." Two other threads ask the same thing in their own words — "I use Sora 2 Pro (199$) but there is no option to remove the watermark. Can someone help?" and "Anyone else on the Pro plan getting downloaded content with an OpenAI watermark? I was under the assumption that the pro plan had them removed?"
So the reports do contradict each other, and it is worth saying plainly that I cannot settle it from here: I have no account on the service and no API key, so the claim about the API is the commenter's, not my measurement. What I can say is what is checkable. The credential this page's tool removes is written into the file by whatever produced it, so it is present or absent in the bytes, and no billing tier can change bytes that are already on your disk. If your plan does give you a clean export, you will not need this page. If it does not, the plan is not the lever — the file is.
People did, and then it stopped. A user on r/OpenAI kept a dated record of it, posted 3 October 2025, quoted as written:
"Day 1 I could create a draft and screen record it without the Sora watermark / Day 2 there's a Sora watermark even on the draft videos / Day 3 now you can't even screen record draft videos anymore your only option is to download the video with the Sora watermark baked in"
Worth understanding what a recording is, because it is not a workaround that removes a layer — it is a way of never copying either one. A capture is a brand-new file made from what the player drew, so it carries no content credential and no mark, at the cost of the original pixels: whatever resolution, frame timing and bitrate the player happened to be showing, plus the player's own scaling. You are trading a clean file for a worse copy of the picture. That is a real trade if the goal is a clip for a phone screen, and a bad one if the goal is the file you paid to generate.
Someone asked exactly that on r/OpenAI, about a $5 monthly plan, in these words: "I wanna buy the $5 monthly plan to remove the sora watermark but apparently its sketchy". The question is fair and the answer is a checklist you can run in two minutes, before you pay anything.
First, does it ask for a share link or for your file? A share-link tool cannot help with a video you already downloaded, which is the only kind of file this page deals with. Second, watch where the bytes go: open DevTools, switch to the Network tab, run the tool, and see whether any request carried your video. If one did, the file left your machine, and what happens to it afterwards is governed by a policy page rather than by the arithmetic. Third, does the result come back as a file you can check? Run ffmpeg -v error -i cleaned.mp4 -f null - and confirm it decodes, and read the box list back with the command further up this page. Fourth, does the page ever tell you what it cannot do? A tool that removes only the file layer and says so is more useful than one that implies it repaired the pixels.
This site's answer to the first question is the reason the tool runs where it does: the container rewrite happens in the tab, on the copy of the file your browser already has, with no upload, no account and no server to send it to.