How accurate is this checker?

This checker does not decide whether an image is AI-generated, so it has no accuracy percentage for that. It reports which provenance signals a file carries and whether a signed record validates. This page shows how we tested those checks, what came out, which versions and trust list dates stand behind the results, and what each check cannot see.

What the checker is built on

Built on c2pa-rs 0.91.7 through c2pa-web 0.15.5. The c2pa-rs library reads and validates Content Credentials. The c2pa-web package compiles it to WebAssembly, so the check runs inside your browser and your image stays on your device.

The library checks a record's signature and its match to the file. We then ask whether a trust list vouches for the signer's certificate, using two copies of trust lists that we host and never fetch from anywhere else at check time.

The Interim Trust List is named as frozen on January 1, 2026. The repository shows its files last changing on the dates above, and we show every date. A signer added to a list after the date of our copy is not recognised until we fetch the list again. Each result names the list it used and its date. The row marked as written by us is a small settings file for the C2PA Trust List. It names the one certificate use that version 2.2 of the specification allows on that list, and it is not a copy of anything the C2PA project publishes. See Privacy and method and What are Content Credentials? for how the two lists are used.

Real files from public collections

We ran the files below through the same code the page uses, in a real browser, under the same Content Security Policy as the live site. The first table counts what the checker showed for each tool's files. The second lists every file that carries a record, with the validator's result against each list.

We ran 32 files through the checker: 29 from Wikimedia Commons categories whose names say they hold images generated by one of 15 tools, two samples published by vendors, and the C2PA project's own test image. The names are the sources' claims; we do not know how any of these files was made. Nine of the 32 carry a Content Credentials record. This is a small test, not a survey.

Names in the certificate are what the certificate says, which anyone can write. They are not a finding about who signed the file.

A validator result of "Valid" means the signature and the match to the file check out. It says nothing about the signer. Whether the signer is vouched for is the second half of each result, and a record can be valid while no list vouches for its signer. The headline column shows what the checker told the visitor.

Files we made to test forged and damaged records

Real files rarely show the cases an attacker or a mistake would produce, so we built some. Each row is a file we made for the test suite; none is shipped to visitors.

Besides real files, we made 18 test files to see how the checker treats forged, damaged and unusual ones. Our development certificate is on neither trust list, so a record signed with it reads as signer trust not established.

A record signed with a self-made certificate that names a well-known company reads the same as a genuine file from that company, because only a trust list can vouch for a certificate and anyone can write any name into one. The checker says this in its result, and it never writes "Signed by" for a name that no list vouches for.

The Stable Diffusion invisible watermark

The checker looks for the invisible pattern that Stable Diffusion's reference software adds, in three payload types. A chance match on an ordinary photograph would be a false claim about that photograph, so we set each threshold by decoding photographs that came from curated collections, in the same browser code the page uses, and chose it above every score we saw. In the table, the threshold is the number of payload bits that must match, the highest photo score is the best match any photograph reached, and the false-match chance is the chance that random bits would reach the threshold.

We checked 250 photographs from Wikimedia Commons categories of curated photographs and 0 of 250 reached a threshold. Each threshold was set so that no photograph reached it and so that a match by chance is very unlikely. Adding the chances for all three payloads, one check has about 5.9 × 10⁻¹⁰ chance of a false match by this model. That is below one in a billion. Commons categories are not proof that a photograph has no generated content; they are the best proxy we had.

Next, we marked test photographs with each payload using the reference software, saved them in different ways, and counted what the checker found. The pattern lives in fine detail of the pixels, so many ordinary steps change what is left of it. Read the table before relying on a "not found" result for an image that has been shared.

0 of 5 unmarked control files matched a payload. The JavaScript decoder read the same bits as the Python reference package on 50 of 50 test files. The marked files and the controls are made from three photographs.

Automated tests

The last full run of our browser test suite was on October 30, 2026. It opened the built site in a real browser and ran 52 groups of checks (1,842 checks in all); every group passed. The suite checks every verdict against the table of expected headlines, that no request leaves the site, and that no console error appears.

What each check cannot see

• Content Credentials. We cannot tell whether what a record claims is true. We see nothing once a record has been stripped, which happens with screenshots and many uploads. We do not ask online whether a certificate was revoked after it signed a file, and we never fetch a record that a file only points to.
• Metadata. Anyone can write or remove it. A label in a file is a label, not proof.
• The invisible watermark. We check one pattern, the one Stable Diffusion's reference software adds. Common edits can remove it, and every other watermark is outside this check.
• Not checked at all. Google's SynthID watermark, Meta's watermark, Adobe TrustMark, visible marks and pixel-based AI detection. See What is SynthID? and visible AI watermarks.

What we do not claim

• We give no detection rate for AI images. There is no list of true answers to score against, and the checker does not guess from pixels.
• We do not say that finding nothing means an image is real or human-made. Most images lose these signals when they are shared.
• We do not say these files are a sample of the images people check. They are a small test, not a survey.
• We say nothing about a tool whose files we did not test.
• The checker is not for legal or evidentiary use.

If a result looks wrong

Write to hello@newwatermark.com. Tell us the headline you saw and where the file came from. Please do not attach the image: we do not receive or keep yours. Security issues go to the same address. To try the checker yourself, check an image.

Frequently asked questions

Does the checker have an accuracy rate?

No. It does not decide whether an image is AI-generated, so there is nothing to score that way. We publish what we tested and how each check behaved instead.

Why can a record that validates still read "signer trust not established"?

A signature can be valid while no trust list vouches for the certificate that made it. Only a trust list can vouch for a certificate, so the checker reports what the certificate names and says that the name is not verified.

How current are the trust lists?

The table above shows the date of each file in our copies. A signer added after those dates is not recognised until we fetch the lists again.

Where do the test files come from?

The real files come from Wikimedia Commons categories, from vendor samples and from the C2PA project's test image. The photographs for the watermark test come from curated Wikimedia Commons categories. We made the forged and damaged files ourselves.