Section 3.3 of the Sora 2 System Card, published by OpenAI on 30 September 2025, is where the company set out what it would do to mark Sora's output. The commitment is three bullet points:
> For general availability, our provenance safety tooling for our First-party (1P) products will include: > > - C2PA metadata on all assets, providing verifiable origin through an industry standard > - Visible moving watermark on videos downloaded from sora.com or the Sora app > - Internal detection tools to help assess whether a certain video or audio was created by our products.
Read the second bullet again. It is scoped — to videos downloaded from sora.com or the Sora app. The first bullet is not scoped; it says all assets. That difference is not decorative.
Does Sora put a watermark on its videos?
Yes, and there are two different marks, which fail in completely different ways. One is a visible moving watermark burned into the pixels. The other is C2PA metadata — a signed record of origin, tucked into the file's container by the software that made it, which anyone can check without trusting whoever sent them the file.
The distinction matters more than the shared word "watermark" suggests. The visible mark is a picture of a claim: it is legible to a person, and anybody with a video editor can burn an identical one onto footage Sora never touched. C2PA is a cryptographic claim: harder to fake, trivially easy to destroy. Neither is a fingerprint in the sense people usually mean: neither is computed from the pixels. They also come off differently. C2PA rides in the file's container, so any rewrite of that container destroys the manifest, while the visible mark is burned into the pixels and a re-encode carries it along.
What exactly did OpenAI say, and did the wording change?
OpenAI's public wording about the visible watermark changed between the launch post and its current revision, from "all outputs" to "Many outputs." The C2PA sentence did not change. Here are the three documents side by side, quoted exactly.
| Document | Date | On the visible mark | On C2PA | | --- | --- | --- | --- | | Sora 2 System Card, §3.3 | 30 Sep 2025 | "Visible moving watermark on videos downloaded from sora.com or the Sora app" | "C2PA metadata on all assets" | | Launching Sora responsibly | 30 Sep 2025 | "At launch, all outputs carry a visible watermark." | "All Sora videos also embed C2PA metadata—an industry-standard signature" | | Creating with Sora safely | 23 Mar 2026 | "Many outputs also carry visible, dynamically moving watermarks which include the name of the creator." | "All Sora videos also embed C2PA metadata—an industry-standard signature" |
The March 2026 page is the current one; it links back to the September 2025 page as "previous version," so this is a revision of the same statement rather than two independent claims. The launch page also described a third mechanism that is not a mark on the file at all: "we maintain internal reverse-image and audio search tools that can trace videos back to Sora with high accuracy." That sentence survives unchanged into the current version. It is a capability OpenAI holds internally. It is not something a reader with a suspicious video can use, and neither page cites an evaluation behind "high accuracy."
Did every Sora video actually carry both marks?
One published test says no — that the two marks appeared in the alternative rather than together. This is a single person's test, so take it as that.
Ethan Le Sage, writing on LessWrong on 6 November 2025 under the title "OpenAI Does Not Appear to be Applying Watermarks Honestly," quoted the launch bullet above and reported: "I have been testing the C2PA metadata accompanied with Sora 2 videos, and to my understanding, this claim is false." He tested with two tools, the official Content Credentials Verify site and the official `c2pa-rs` command-line tool. On a visibly watermarked download he wrote that the video "is prominently watermarked with a visible Sora watermark. However, I can't find any invisible C2PA data attached, as is claimed to exist by OpenAI," and that the Verify tool "was not able to identify any metadata." On the other side he reported: "It appears that, if a Pro user downloads a video without the visible watermark, then the invisible C2PA metadata is included." He noted that all users except those on the $200/month Pro plan were restricted to downloading videos with visible watermarks.
His own disclaimer, quoted in full, is the right frame for the result: "The claims in this post are 'to my knowledge', and I am not a cyber-security or cryptography expert. All claims are made according to the results of my testing using the Content Authenticity Verify and C2PA-rs tools. These tests were performed on videos downloaded using the Sora 2 web interface on Windows Desktop."
That is one person, one web interface, one operating system, and no stated sample size. We have not reproduced it, and we have never run a Sora file through our own engine. Set it beside the table above and note only what is verifiable: OpenAI revised the sentence about the visible mark and left the sentence about C2PA reading "All." The revision therefore does not speak to Le Sage's finding in either direction. Both documents are public and dated; a reader can check them.
Is Sora still running?
The app is not. OpenAI's help centre states that "The Sora web and app experiences were discontinued on April 26, 2026" and that "The Sora API will be discontinued on September 24, 2026." Both safety pages now carry the line "As of April 26, 2026, the Sora product is no longer available."
This has a consequence people miss. At the time of writing, the only Sora video still being generated is API output — and API output is exactly the category the visible-watermark bullet never covered, since that bullet was scoped to downloads from sora.com and the Sora app. Meanwhile the videos already made did not go anywhere. Discontinuing a generator does not recall its output, and clips produced between launch and April will keep circulating long after September. Whatever marks those files carry are the marks they will always carry.
How hard is it to remove the mark?
C2PA comes off by accident. The visible mark takes deliberate effort, and there is a market supplying it.
On the C2PA side we can offer our own measurement rather than an argument. Our video corpus includes a C2PA-signed clip from the Coalition for Content Provenance and Authenticity's public test files. A single `-c copy` remux — an operation that re-encodes nothing, merely rewrites the container — replaced the file's writer string and destroyed its C2PA box outright. That is recorded in `evidence/DETECTION-STATUS.md`. No attacker is required for this. Any pipeline that rewrites the container does it incidentally, so a clip that has been through a transcode reads as unmarked whatever it started as.
The visible mark is harder, which is the point of making it move. Le Sage raised cropping himself and observed that it "would require cropping out a large proportion of the original video" — a moving mark is designed against precisely the rectangle-crop that defeats a fixed one. The contrast is visible in our own corpus: the Pika clip's mark reads "PIKA LABS," static, bottom-right, and a crop takes it off. Beyond cropping, searching for the mark by name returns multiple commercial services whose entire product is removing it. We are not linking to them; their existence is the relevant fact.
What does a missing watermark tell you?
Nothing. This is the single most important thing on this page, and it holds regardless of which of the claims above turns out to be right.
An unmarked clip is consistent with at least four histories: it was never marked, because the promise did not cover how it was produced; it was marked and a platform stripped the metadata during a routine transcode; it was marked and someone removed it on purpose; or it came from a generator that never marked anything in the first place.
Our own corpus makes the last case concrete. It holds six generated clips — none of them Sora — and exactly one carried a visible mark: the Pika clip. The Google, Kling, CogVideoX-2B, CogVideoX-5B and Mochi 1 samples were clean. Exactly one carried C2PA, the Google-signed file, and that one our engine settles outright: verdict `ai`, 97, at proof tier, decided by the signature alone. That is n = 1 — one generator, one file — and it is not a coverage rate. The other five return `uncertain`, 50, with a range of 20 to 80, because nothing in the video lane can speak about a file that carries no provenance.
So the asymmetry is sharp, and it is the conclusion worth keeping. A mark that is present and verifies is decent evidence — a valid generative C2PA manifest is strong enough that our engine decides on it. A mark that is absent is no evidence at all, about anything.
What can you do with a clip you cannot verify?
Check for the mark first, because checking is free and settles the question outright when it succeeds. Then accept that a negative result is not an answer, and stop treating it as one.
Check C2PA with the official Content Credentials Verify site or the official `c2pa-rs` command-line tool — both are free, both are what Le Sage used, and neither is sold by a detection vendor, ourselves included. Check the original file rather than a re-share, since a re-share has almost certainly been transcoded and will read as unmarked whatever it started as.
If that comes back empty, the honest position is that you do not know. There is no pixel-based fallback we would ask you to trust: the deployable set of open synthetic-video detectors is empty on licence, missing weights, or measured accuracy, and image detectors applied to video frames lose most of their edge. Our own video lane has five rungs of evidence and only the signature rung can decide anything.
What that means in practice is that unsigned video gets `uncertain` from us and will keep getting it. It also means the one verdict this product can never return on a video is `human`: clearing a file requires positive provenance of those exact bytes, and a missing watermark is the absence of evidence, not evidence of a person.
