Content authenticity
Verify what the video really is.
Drop an AI-generated video — it reads the C2PA content credential and reports the real model tier, resolution and integrity. Everything runs in your browser; the file is never uploaded.
Four levels of evidence — not all “AI labels” are equal
This tool reads whatever provenance a file carries and places it on one of four rungs. Only the top rung is cryptographic; the rest are self-declared and can be forged or stripped. We report the rung and the honest limits of each.
Strong — cryptographic (C2PA) — Signature + hash, independently verifiable. Catches tier / resolution fraud.
Moderate — platform-declared — AIGC metadata, ProduceID, platform trace id (e.g. Jimeng / Dreamina). Unsigned — forgeable & strippable.
Weak — loose hints — Encoder, comment, filename. Common in AI files, but proves nothing.
None — no markers — Nothing readable. Not proof the file isn’t AI.
Try it on real outputs
Click any file — it verifies live in your browser, nothing uploaded. Real outputs we tested on 2026-07-10.
Credential we pin — Seedance via BytePlus (green)
Signed, but issuer not pinned (amber)
Platform-declared metadata, not C2PA — Jimeng / Dreamina (cyan)
No verifiable credential (gray)
Also tested, no C2PA credential: Grok (xAI) · Wan 2.5 (Alibaba). Jimeng / Dreamina carries unsigned AIGC metadata (cyan) — moderate, not cryptographic.
We tested the market
Each row is a provider’s own public sample, dropped into this same tool on 2026-07-10. The dot is what it shows here: green = credential from an issuer we pin · amber = validly signed but issuer not pinned · cyan = unsigned platform AIGC metadata (not C2PA) · gray = no verifiable credential.
| Model | Provider | C2PA |
|---|---|---|
| Seedance 2.0 (full) | ByteDance · BytePlus | yes |
| Seedance 2.0 Fast | ByteDance · BytePlus | yes |
| Seedance 2.0 Mini | ByteDance · BytePlus | yes |
| Google Veo 3.1 | yes | |
| Kling v3 Pro | Kuaishou | — |
| Grok Imagine v1.5 | xAI | — |
| Hailuo 2.3 | MiniMax | — |
| Luma Ray 3.2 | Luma | — |
| Wan 2.5 / 2.2 | Alibaba | — |
| Hunyuan Video 1.5 | Tencent | — |
| Pika v2.2 | Pika | — |
| PixVerse v5 | PixVerse | — |
| Seedream 4 (image) | ByteDance | — |
| 即梦 Jimeng / Dreamina | ByteDance | — |
Documented C2PA signers we couldn’t retest here (auth-gated, not publicly downloadable): OpenAI Sora and Adobe Firefly — each signs with its own certificate, so both would read amber (recognized issuer), not green. The standard is spreading — Adobe, Google and OpenAI all sign — but as of testing most video models still ship nothing to verify.
C2PA / Content Credentials is an open Linux Foundation standard (Adobe, Microsoft, BBC, Google, OpenAI…). Embedding it is a provider’s choice to make provenance verifiable; as of testing, most video models don’t yet. We pin BytePlus (Seedance) and read its tier SKU — which even other signed formats don’t expose.
Frequently asked questions
What does this tool actually check?+
It reads the video’s C2PA content credential — a cryptographically signed manifest that some AI generators (including BytePlus ModelArk, which serves Seedance) embed at generation time. The credential records which model produced the file (down to the exact SKU, e.g. dreamina-seedance-2-0-fast), when, and a cryptographic hash of the video bytes. We verify the signature, the certificate chain, and whether the file still matches its hash.
Can someone fake a green result?+
To forge a green (“issuer pinned”) result, an attacker would need the issuer’s private signing key. Producing a valid signature without it is what digital-signature schemes are mathematically designed to prevent (see the cryptography section below). What an attacker can do is self-sign a manifest with any claims they like — which is exactly why this tool treats claims from unrecognized issuers as self-declared, not fact (the amber state).
The result says “no verifiable credential.” Does that mean the video is fake?+
No — and it’s not proof of authenticity either. A credential is routinely dropped by ordinary post-processing done with tools that don’t carry Content Credentials forward: editing, adding effects, subtitles or overlays, color grading, re-encoding, exporting from a video tool, or re-uploading through platforms that re-compress. So a polished clip that is genuine AI output will still read “no credential.” What that means: this file, as delivered, can’t prove what model made it or whether it was altered. When a credential is present, it cryptographically proves which model made the file and that it hasn’t changed since — that is the artifact worth asking for. To check it, verify the original API file (the version before any post-processing), and ask your supplier for that file if you don’t hold it.
A polished demo or showcase clip shows no credential. Does that mean it isn’t AI-generated?+
A no-credential result can’t tell you either way — it’s equally consistent with genuine model output that was post-processed and with a file that isn’t what it claims. For a finished showcase reel, though, no credential is the expected result: presentation steps — trimming, grading, captioning, re-encoding, exporting from an editor — typically strip the C2PA credential and any metadata-embedded AIGC label (a visible AI watermark, if one was burned in, still shows). Those labels survive reliably only on the untouched API file. So gray on a showcase clip isn’t a red flag on its own — but it isn’t a green light either. It does warrant a question in one case: if a file was handed to you as the raw original, or as a specific model tier you paid a premium for, and it still reads gray — ask your supplier for the credentialed original, the file this tool is built to verify. A supplier who can’t produce one can’t prove what they delivered.
What’s a “model tier,” and why does the SKU matter?+
Seedance 2.0 ships in multiple tiers — full, Fast, Mini — at very different prices and quality levels. The credential’s model_name field records the exact SKU that generated the file. If you paid for full 2.0 and the credential says -fast, you now know something your invoice didn’t tell you. A tier dictionary is on this page; we state facts about the file and leave conclusions to you.
Is my video uploaded to your server?+
No. Verification runs entirely in your browser via WebAssembly (the open-source c2pa-web library from the Content Authenticity Initiative). You can confirm this yourself: open DevTools → Network while verifying — you’ll see no upload request.
Do I have to trust HolyCrab for the result to be valid?+
No — and that’s the point. C2PA verification is deterministic public-key math; any implementation reaches the same verdict. You can reproduce our result from the command line with the CAI’s open-source c2patool: run “c2patool your-video.mp4 --detailed” and inspect validation_state, the signature issuer, and the model_name assertion. The only judgment we add is which issuers we pin as recognized — and we disclose that list on this page.
Is this endorsed by BytePlus or ByteDance?+
No. We pin BytePlus’s public signing certificate — that is our statement that we recognize their chain, not their endorsement of us. We are a reseller with a direct BytePlus agreement; verification results are facts produced by public cryptography, not by any business relationship.
Someone sent me a video claiming it’s Seedance 2.5. Can I check?+
Yes — drop it in. If it carries a valid credential from a pinned issuer, the model_name tells you exactly which model and tier generated it. A file that claims 2.5 but carries a 2.0 SKU — or no credential at all — is telling you something. (We update our SKU dictionary the day new models ship.)
What can this tool NOT tell me?+
It cannot prove an uncredentialed file is fake (see above). It cannot tell you whether content is true, legal, or licensed — provenance is not rights clearance. It cannot yet prove who supplied a file to you (the credential proves which service generated it; supplier-level attribution is on our roadmap). And heuristics like “this looks upscaled” are signals, not verdicts — we don’t ship them yet.
A video I bought failed verification. What should I do?+
Don’t accuse — ask. Post-production commonly strips credentials, so the first step is to request the credentialed original (the raw API output before any editing). A supplier selling genuine tiers can always produce it. Use the copy-paste request template below.
Don't trust this page — reproduce it
The credential is a standard C2PA manifest embedded in the file. You don’t have to trust our UI: install the open-source c2patool and read the same signature, model and integrity yourself.
c2patool your-video.mp4 --detailed
Why you can trust the math (and don’t have to trust us)
1. Digital signatures — existential unforgeability.
A C2PA manifest is signed with the issuer’s private key (COSE Sign1, RFC 9052; typically ECDSA or RSA-PSS). The security property — existential unforgeability under chosen-message attack (EUF-CMA), formalized by Goldwasser, Micali & Rivest (1988) — means an attacker who sees any number of valid signatures still cannot produce a new valid signature on any new message without the private key. Practical parameters (P-256 / RSA-2048+, per NIST FIPS 186-5) put forgery beyond reach of known computation. This is the same machinery that secures TLS and code signing — and, if you’re from the crypto world, the same primitive as a wallet signature: the manifest is a signed message; the model provider is the signer.
2. Hash binding — why one re-encode breaks everything.
The manifest doesn’t just describe the video; it binds to it via a cryptographic hash of the media boxes (C2PA “hard binding”; for MP4 this is the BMFF v2 hash over the ISO Base Media File Format structure, ISO/IEC 14496-12). SHA-256’s collision resistance (NIST FIPS 180-4) means you cannot construct a different video with the same hash. Upscale 480p→720p, re-encode, trim one frame — the bytes change, the hash no longer matches, and verification reports exactly that. Resolution fraud and tier fraud aren’t “detected” by heuristics here; they’re excluded by arithmetic.
3. Certificate chains — who is the signer, really?
A signature proves possession of a key, not identity. Identity comes from an X.509 certificate chain (RFC 5280): the signing certificate is itself signed by an issuing CA, up to a root. Anyone can self-sign a certificate that claims any name — which is why this page distinguishes a pinned chain (we verified the actual certificate, not its display name, against a registry we publish) from an unknown one (signature internally consistent; claims treated as self-declared). Pinning is the same trust decision browsers make with their root stores, made explicit and narrow.
4. The C2PA standard — who’s behind it.
C2PA (Coalition for Content Provenance and Authenticity) is an open Linux Foundation / Joint Development Foundation specification driven by Adobe, Microsoft, Intel, BBC, Sony, Google, OpenAI and others, growing out of the Content Authenticity Initiative (CAI) and Project Origin. The manifest lives in a JUMBF container (ISO/IEC 19566-5) embedded in the asset. Verification semantics — well-formed → valid → trusted — are defined by the spec, not by us. Our verifier is a thin, reproducible client over an open standard.
5. What cryptography cannot do (honest limits).
Provenance ≠ truth: a signed file proves which service generated these bytes and that they’re unaltered — not that the content depicts reality, nor who holds rights. Absence of a credential proves nothing by itself (stripping is trivial and often innocent). And trust lists are a governance choice: we publish ours. These limits are why this page reports facts, four states, and nothing else.
We tried to forge a green result — it went amber
Provenance you can’t stress-test is just a logo, so we ran the attack ourselves. We generated a self-signed certificate that copies BytePlus’s exact subject name (O=Byteplus Pte. Ltd., CN=certificate@byteplus.com), signed a video with it, and had that video’s manifest falsely claim the full Seedance 2.0 tier. The signature is cryptographically valid and the integrity hash checks out — a convincing fake. Verified here, it returns amber, “issuer not recognized,” with the claimed tier marked “self-declared, NOT verified” — never green. That is the whole point of pinning: green requires the actual pinned certificate and its private key, which copying a display name does not grant. Anyone can sign a manifest; no one can forge our pinned issuer without its key.
Reproduce the attack yourself — c2patool + openssl are open source ↗References
- C2PA Specification (v2.x), Coalition for Content Provenance and Authenticity ↗
- Content Authenticity Initiative — c2pa-web / c2patool (open source) ↗
- RFC 9052 — CBOR Object Signing and Encryption (COSE): Structures and Process ↗
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile ↗
- NIST FIPS 186-5 — Digital Signature Standard (with FIPS 180-4, Secure Hash Standard) ↗
- Goldwasser, Micali & Rivest (1988), A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks, SIAM J. Computing 17(2) ↗
- Diffie & Hellman (1976), New Directions in Cryptography, IEEE Trans. Information Theory ↗
- ISO/IEC 14496-12 (ISO base media file format); ISO/IEC 19566-5 (JUMBF) ↗
- RFC 6962 — Certificate Transparency ↗
Verification runs client-side via c2pa-web (WebAssembly) — no upload. Open DevTools → Network to confirm nothing leaves your browser. It proves provenance, not rights clearance. “No credential” means this file carries no verifiable provenance — expected once a clip has been edited or re-encoded, and not proof either way. Verify the original API file, or ask your supplier for it, rather than an edited export.