Does your published content still carry its mark after it leaves your stack?
C2PA Content Credentials get signed correctly at generation — and then removed silently in delivery. Image CDNs strip the manifest on resize or re-encode; audio and video lose it to transcodes, muxing, and a customer’s re-export. No error, no log, nothing in the response that says it happened. If you came from my email, this page is the evidence behind it.
Evidence
One signed image. Three delivery paths.
I signed a single image with c2patool and published it at a public URL, then requested it four ways through wsrv.nl, a public image CDN. One path asked the CDN for no transformation at all. Every URL below is live — open any of them and check it yourself.
| Delivery path | Bytes served | Relative size | Content Credentials |
|---|---|---|---|
| Direct from origin (no CDN) | 238,584 | Intact | |
| CDN, no transform requested | 159,398 | Stripped | |
| CDN, resize to 800px | 41,624 | Stripped | |
| CDN, resize 800px + WebP | 16,108 | Stripped |
Same source file · c2patool 0.27.16 · 2026-08-29 UTC · Each verdict is c2patool run against the delivered file, never inferred from byte count. Source: asset-signed.jpg — and the three CDN paths, live: no transform · resize 800 · resize 800 + WebP. These are the exact URLs recorded in section 03 of the sample report. All four return Error: No claim found or an active manifest; nothing in between.
What this test proves — and what it doesn't
It proves: the manifest does not survive this CDN — and the second row is why that matters. That request asked for no transformation. No resize, no format change. The manifest was gone anyway, because the CDN re-encodes by default and a JPEG re-encode discards the JUMBF box the manifest lives in. Credential loss here is not something you opt into by resizing.
And byte size is not the evidence. If your first thought was "you shrank the image, of course it's smaller" — correct, and that's why row two exists at the original dimensions, and why every verdict above comes from the tool rather than the file size.
It does not prove anything about your pipeline. This was my own test asset on my own CDN, and your setup is not mine. The problem is that nothing in your stack reports either way, so the honest answer today is that you don't know, and neither do I. The audit replaces "don't know" with a dated record of which one it is.
The free verifier at verify.contentauthenticity.org checks one file in about four seconds, and you should use it — but run it on a delivered URL, the one your CDN actually serves a customer, not the file sitting in your bucket. That single result is the first line of the report. What it won't give you is which step of your pipeline removed the manifest, coverage across the URLs you publish, or a dated document a procurement team will accept. That gap is what $290 buys.
Deliverable
What $290 buys
You send the public URLs of the assets you publish. Five business days later you have a dated PDF you can attach, unedited, to a customer's vendor questionnaire — checked by hand, one URL at a time.
And if every asset passes, that's the good outcome and the report is still the artifact: a dated, third-party-timestamped record that they passed, which is exactly what the questionnaire is asking for.
- 01
Executive summary
One page that reads on its own — asset count, pass/fail counts, date in UTC. This is the page that gets forwarded; the rest is the backup.
- 02
Scope and limits, in writing
Tool and version, what was checked, what was not checked, and why — including a standing section on what the report does not establish. This is the part that holds up when your customer's auditor pushes back.
- 03
Per-URL results
Every asset in one of three states: credentials intact, credentials present but failing validation, or no manifest at all.
- 04
Root cause, per asset
Where the mark died and which step killed it — signed at origin then stripped downstream, or never signed at generation. With a specific fix for each case: excluding the asset from the transform, moving to a remote manifest so the credential survives re-encoding, or adding a soft binding or durable content credential where the container can’t carry the manifest at all.
- 05
Copy-paste questionnaire answers
Drafted responses to the questions procurement actually asks, in language you can paste without editing.
- 06
Cryptographic timestamp
A SHA-256 digest of the report, sealed with an RFC 3161 timestamp from a third-party authority, plus instructions to verify it independently of me.
Read one before you buy
The audit at the top of this page was issued as a real report, in exactly the format above — the same six sections, the same limits section, the same timestamp. It is published in full, because asking you to buy a document sight unseen from someone you have never heard of is not a reasonable request.
PM-2026-0001.pdf · RFC 3161 token (.tsr)
Verify the seal yourself. Six lines, one directory, nothing to install on macOS or Linux — and no part of it contacts me:
mkdir pm && cd pm curl -O https://tayyir.com/proof/PM-2026-0001.pdf curl -O https://tayyir.com/proof/PM-2026-0001.pdf.tsr curl -O https://freetsa.org/files/cacert.pem curl -O https://freetsa.org/files/tsa.crt openssl ts -verify -data PM-2026-0001.pdf \ -in PM-2026-0001.pdf.tsr \ -CAfile cacert.pem -untrusted tsa.crt
The last line prints Verification: OK. Everything it needs is downloaded above it, so if it prints anything else, the document really has been altered — and you should not trust anything else on this page either.
Nothing in the report asks you to take my word for it. Every finding is a URL and a command you can re-run in your own terminal — and the timestamp means that once the report is issued, not even I can change what it says.
What this is not
ProofMark reads and verifies. It does not sign. Verification reads public certificates out of the manifest — no private key is involved on either side, so there is nothing of yours for me to hold. No SDK to install, no certificate to obtain, nothing about your build changes.
The alternative
Running c2patool against your URLs is an afternoon with a shell script. I'm not going to pretend otherwise.
The afternoon isn’t the problem. The problem is that the output of an afternoon is a terminal buffer on your laptop, and what your customer’s reviewer asked for is a dated document with a stated method, stated limits, and a third-party timestamp on it. That document isn’t hard to write either — it just never reaches the top of your engineer’s list, and it stays not-written until a deal is waiting on it. That second part is what you’re buying. It’s $290.
Eligibility
Who this is for — and who it isn't
Worth $290 to you if
- You generate synthetic media — image, video, or voice — published under your own name
- You distribute it through your own pipeline: CDN, marketing site, customer embeds
- Enterprise customers send you vendor security questionnaires, or you keep a trust page
- You're roughly 15–150 people, so questionnaires land on an engineer rather than a compliance team
Don't buy this if
- Your product summarizes, classifies, or extracts — it doesn't generate synthetic media. There's nothing to mark and nothing to check
- Your output is machine-to-machine and never reaches a human audience
- No customer has ever sent you a security questionnaire
- You can already produce a dated, third-party-verifiable record of credential coverage across the assets your customers actually ask about — that record is the entire deliverable, so you don’t need me
If you're on the second list, reply and say so. I'll tell you not to buy it.
Request
Order an audit
- Up to 25 published URLs — the ones your customers ask about, not your whole library. Publishing thousands doesn’t change that: pick the 25 that would appear in a questionnaire. More than 25, email first and I’ll either quote it or tell you it’s the same price.
- Delivery in 5 business days from the moment you send your URLs.
- Full refund, no questions — if it arrives late, or if the report isn’t something you’d be willing to hand a customer as it stands. Reply and ask; I won’t ask why.
- Checked by hand, not by a crawler. Every report is signed by Hamza, who is the only person at Tayyir and the person who answers hamza@tayyir.com.
- Your URLs and your results stay between us. I don't publish client findings, named or anonymized.
After payment: an intake email within one business hour asking for your URLs. The report arrives as a PDF within 5 business days of your reply, with the RFC 3161 token attached as a separate .tsr file. No call, no onboarding, no account to create.