I Tried to Build an AI Image Detector. Instead, I Learned What C2PA Actually Does

I started this project with a simple assumption: if I took an arbitrary image, perhaps one generated by an online AI service, a validator could tell me where it came from.

Was it created by a camera? Generated by AI? Which application produced it? Had someone modified it afterward?

That assumption was wrong.

Once I started learning about C2PA Content Credentials and experimenting with Google’s open-source Credentio library, the distinction became clear. C2PA is not an AI detector. It does not analyze pixels and guess how an image was created. It verifies cryptographically signed provenance information when that information is available.

To see what that means in practice, I built Credentio Local Checker, a small open-source web interface that runs the validation process locally.

The question I originally wanted to answer

The verification tool I had in mind would take an image from an unknown source and return a simple answer:

• this photograph came from a camera;
• this image was generated by an AI model;
• this file was edited;
• or its origin is unknown.

C2PA works differently. It does not independently discover a file’s origin. Instead, it defines a standard for attaching a signed provenance record to digital media.

A participating camera, application, or AI service can create a C2PA manifest containing claims about how an asset was produced or modified. Those claims are cryptographically signed and embedded in, or associated with, the asset. A validator can then inspect that record and check whether it remains valid.

The key distinction is:

C2PA does not determine what happened. It verifies signed statements about what happened.

What Content Credentials can tell us

Depending on what the creator or application recorded, Content Credentials may describe:

• the application or device that created the asset;
• the organization that signed it;
• editing actions;
• the use of a generative model;
• relationships between an original asset and its derivatives;
• other provenance assertions.

A validator can check whether:

1. a C2PA manifest is present;
2. its structure is valid;
3. the current file still matches the signed content hash;
4. its signatures are cryptographically valid;
5. the signing certificate can be validated against the configured trust list;
6. the assertions form a consistent provenance chain.

That is useful evidence, but it is not proof that the image itself is true.

A valid signature can confirm the integrity of the signed provenance data. It cannot confirm that the scene depicted in the image actually happened in the real world. Trust still depends on who signed the claims and what those claims say.

Three results that should not be confused

The most important interface decision was not to reduce validation to a red or green “real or fake” indicator. The validator can produce at least three fundamentally different outcomes.

1. Valid Content Credentials

A manifest was found, its integrity checks passed, and its signatures could be validated.

This is a positive technical signal: the signed provenance record passed validation. It does not automatically make every claim in that record objectively true.

2. An integrity problem was detected

The file contains Content Credentials, but one or more validation checks failed.

For example, the current content hash may no longer match the value covered by the signature. That can indicate that the asset changed after the provenance record was created.

3. No Content Credentials were found

This is a neutral result, not a validation failure.

The file might be:

• an untouched photograph;
• an edited photograph;
• an AI-generated image;
• a screenshot;
• a copy processed by software that removed metadata;
• or an asset created before C2PA support was available.

The absence of Content Credentials proves none of these possibilities. Calling such a file “real” or “fake” would go beyond the available evidence.

Why I used Google Credentio

On August 13, 2026, Google introduced Credentio, an open-source C++ library for validating C2PA Content Credentials.

The source code is published through Google’s Media Provenance repository under the Apache License 2.0.

Credentio can validate supported image, video, audio, and document formats. It can also produce a machine-readable crJSON result containing manifests, validation statuses, signatures, and provenance assertions.

The library gave me the validation engine I needed, but not an end-user interface. I built a small local web layer around it.

The most surprising result was not the tampered file. It was the unsigned one. The validator could not tell me whether it was authentic, edited, or generated. That was the correct answer.

How the local checker works

The architecture is deliberately simple:

Browser
   ↓
Local Node.js server on 127.0.0.1
   ↓
Permission-restricted temporary file
   ↓
Locally built Credentio C++ validator
   ↓
crJSON result
   ↓
Human-readable report in the browser

The user selects an asset in the browser. The browser sends it to a Node.js process running on the same computer. The server passes the temporary file to the locally built Credentio binary, parses the result, returns a summary to the browser, and deletes the temporary file afterward.

The interface reports:

• the number of manifests;
• successful checks;
• validation failures;
• trusted signatures;
• detected signers;
• individual failed checks;
• and the complete crJSON result when requested.

This is not a hosted verification service. The application binds only to the loopback interface and is intended to run on the user’s own computer.

Testing four different cases

The project includes four public reference assets, so its behavior can be tested without first finding C2PA-enabled media elsewhere.

Valid signed JPEG

The first sample contains valid Content Credentials. Credentio reports:

• 4 manifests;
• 40 successful checks;
• 0 failures;
• 4 of 4 trusted signatures;
• Google LLC as the signer.

This is the cleanest result: the manifests are present, their associated content passes validation, and the signatures can be linked to the configured trust list.

Modified JPEG

The second sample contains credentials related to the same provenance chain, but its content no longer matches the signed hash. The result contains:

• 4 manifests;
• 39 successful checks;
• 1 failure;
• the validation code assertion.dataHash.mismatch.

This is why finding a manifest is not enough. The validator also has to confirm that the current asset still matches the content covered by the provenance record.

JPEG without Content Credentials

The third sample has no C2PA manifest. The interface deliberately treats this as a separate neutral state rather than a validation failure.

Calling the file “fake” would go beyond the available evidence. The validator can only say that no Content Credentials were found.

Valid signed MP4

The fourth sample shows that the same approach also applies to video. Credentio reports:

• 2 manifests;
• 19 successful checks;
• 0 failures;
• 2 of 2 trusted signatures.

Keeping the file local

Media files can contain more than visible pixels or frames. Their metadata may include information about authorship, software, devices, timestamps, and editing history. I did not want this experiment to depend on uploading private assets to an external verification API.

The project therefore applies several local-first restrictions:

• the server listens only on 127.0.0.1;
• selected assets are not uploaded to Google or another cloud service;
• temporary directories use owner-only permissions;
• temporary assets are removed after validation;
• cross-origin upload requests are rejected;
• the interface is served with a restrictive Content Security Policy;
• raw crJSON remains in the local browser.

The initial setup still requires an internet connection because it downloads pinned source revisions, trust lists, dependencies, and public test assets. Once the runtime has been built, validation is performed by the local Credentio binary.

Reproducible setup

Credentio is a C++ project built with Bazel.

To reduce the chance that a future dependency update silently changes the experiment, the setup process pins known revisions of:

• Credentio;
• Android LibCppBor;
• the C2PA trust lists;
• public reference assets.

The setup script verifies SHA-256 checksums for downloaded trust lists and samples. Generated dependencies and binaries are kept in an ignored .runtime directory rather than committed to the repository.

The current setup targets macOS and has been tested on Apple Silicon.

npm install
npm run setup
npm start

The interface then becomes available at:

http://127.0.0.1:3210

The first native build can take several minutes. Subsequent builds benefit from Bazel’s local cache.

What the project does not do

Credentio Local Checker does not:

• classify media by analyzing pixels, frames, or audio;
• search the internet for the original source;
• prove that a depicted event is factual;
• recover Content Credentials that were removed;
• add or sign new Content Credentials.

It is an experimental validation interface, not a production fact-checking service.

What I learned

My original question was too broad. There is no universal metadata check that can take any arbitrary image and reliably identify where it came from. Provenance verification depends on provenance data being created, preserved, and trusted across the content lifecycle.

For C2PA to provide a meaningful signal:

1. a device or application must create the credentials;
2. editing tools must preserve or extend them;
3. distribution platforms must avoid stripping them;
4. the recipient must validate the signatures;
5. the recipient must decide whether the signer is trustworthy.

If part of that chain is missing, the conclusion becomes weaker.

That does not make C2PA useless. It means the standard solves a more precise problem than “detect fake content.” A better description is:

C2PA provides infrastructure for making verifiable claims about the provenance of digital media.

It cannot establish truth on its own. What it can do is make a file’s recorded history more transparent and make certain kinds of undeclared modification detectable, provided the provenance chain exists and can be validated.

Project links

• Project page
• Source code on GitHub
• Google Credentio announcement
• C2PA specification and resources

Credentio Local Checker is an independent experimental project. It is not an official Google or C2PA product and is not endorsed by either organization.