Inspector de credenciales de contenido (C2PA) online
Las credenciales de contenido (C2PA) son registros de procedencia firmados que cámaras, editores y generadores de IA incrustan en imágenes, video, audio y documentos. Suelta un archivo para leerlas con c2pa-rs, la implementación de referencia de C2PA, que se ejecuta en tu navegador como WebAssembly: se muestran la cadena de manifiestos, las acciones, los ingredientes y los resultados de validación, y el archivo nunca se sube.
El lector de C2PA (WebAssembly de este sitio) lee el archivo en esta pestaña del navegador; nunca se sube, y los manifiestos remotos no se descargan.
Archivo de imagen, video o audio
Suelta aquí un archivo de imagen, video o audio, o
JPEG, PNG, WebP, AVIF, HEIC, TIFF, GIF, SVG, MP4, MOV, WAV, MP3, PDF y más, hasta 1 GB.
Anclas de confianza (opcional)
Que un firmante sea de confianza depende de una lista de confianza. Las aplicaciones de credenciales de contenido usan la lista de confianza de C2PA, con los productos conformes; esta página no incluye ninguna, así que las credenciales intactas aparecen como «sin confianza» hasta que añadas las raíces en las que confías. Solo certificados: no se descarga ninguna URL y se rechazan las claves privadas.
Ejemplos
Imágenes de prueba de c2pa-rs (C.jpg y CA.jpg de sus datos de prueba, MIT o Apache-2.0) y sus raíces de prueba «C2PA Test Root CA — FOR TESTING ONLY», cargadas como anclas de confianza donde el ejemplo las necesita. El ejemplo modificado invierte un bit de los datos de la imagen en tu navegador.
What Content Credentials are
Content Credentials are the C2PA standard's signed provenance records (C2PA specification 2.x). A camera, an editor or an AI generator that supports them embeds a manifest in the file — in a JUMBF box of a JPEG or PNG, a box of an MP4 or HEIC, a chunk of a WAV. A manifest holds assertions (what was done: actions, ingredients, the author, training and mining preferences, a thumbnail), a claim that lists the hashes of those assertions and binds them to the file's content, and a COSE signature over the claim with an X.509 certificate of the signer. Every edit by a C2PA-aware tool adds a new manifest that names the previous file as an ingredient, so a file can carry a whole chain of provenance.
Credentials prove who signed which claims and that nothing changed since. They do not prove the claims are true: a signer can lie, and the value of a manifest is the value of its signer.
How the file is read
The inspector does not reimplement the standard. It runs c2pa-rs, the C2PA reference implementation, compiled to WebAssembly (@contentauth/c2pa-web, MIT) in a Web Worker of this page. The reader — about 9 MB — is downloaded from this site the first time you inspect a file and is not part of the page otherwise. It validates exactly what the specification requires:
- Hard binding — the hash of the file's content outside the manifest. If a single pixel or audio sample changed after signing, the binding no longer matches and the file is reported as changed.
- Assertions — every assertion's hash against the claim, so edited or removed assertions are caught.
- Claim signature — the COSE signature over the claim, the signing certificate's profile and validity, and an embedded RFC 3161 time-stamp, if present.
- Ingredients — the manifests of earlier versions embedded in the file, with their own signatures.
The page turns the reader's validation codes into checks and keeps the codes themselves under Validation codes, with the reader's explanations.
Trusted, valid, not valid
C2PA distinguishes a manifest that is well-formed and intact from one whose signer is trusted. Trust needs a trust list: Content Credentials apps use the C2PA conformance program's list of products and certificate authorities. The inspector bundles none and fetches none, so an intact manifest is reported as intact, but the signer is not trusted until you paste the roots you rely on under Trust anchors. The examples load the c2pa-rs test roots this way. A manifest whose content, assertions or signature fail is not valid, whatever its signer.
Reading the AI labels
Actions and ingredients may carry an IPTC digital source type. The inspector summarises the whole chain:
trainedAlgorithmicMedia on the creation action of the latest manifest means created by generative AI;
compositeWithTrainedAlgorithmicMedia, or a generative source anywhere else in the chain, means generative AI was
used; algorithmicMedia and similar codes mean created or changed by an algorithm that is not trained AI. Captured and human-made sources raise no label. The
label repeats what the signed manifest states — it is not a detector, and a file without credentials says nothing
either way. Training and mining preferences (c2pa.training-mining) are listed as the creator set them.
What stays on your device
The file is read with the File API and processed in this tab; it is never uploaded. Two features of C2PA readers would contact other servers, and both are switched off: remote manifests, credentials stored at a URL named in the file, are reported but not fetched, and OCSP revocation checks of the signing certificate are not made. Either request would tell a server which file you are looking at. The preview of your image and the stored thumbnail are shown from local object URLs.
Social networks and messengers often strip metadata when they re-encode an upload, credentials included. If an image you expected to be signed shows none, look for the original file. Certificates inside the manifests can be read in full in the certificate decoder, and signed time-stamps in the time-stamp inspector.