Glossary of image provenance terms
Every term and acronym that appears in an AuditImage report or in these guides, from APP1 to XMP, spelled out and explained in a few sentences each.
A report from this site names a lot of things: segments, chunks, manifests, assertions, trust anchors. This page defines each of them once, grouped by where you meet them. Terms are in bold, and every acronym is followed by its full spelling in parentheses the first time it appears. The guides linked at the end of each section go deeper.
The verdict and the report
- Provenance — Where a picture came from and what happened to it since: captured by a camera, generated by a model, edited by a program, or some chain of those. Everything this site does is an attempt to read provenance out of the file itself.
- Verdict — The one-line conclusion at the top of a report. It is chosen by priority: a valid or invalid Content Credential outranks a self-declaration in metadata, which outranks a contradiction, which outranks a plain camera EXIF block, which outranks metadata that says nothing about origin.
- Finding — One observation with a level (info, notice, warning). A report is a verdict plus its findings; the verdict is derived from the findings, never the other way round.
- AI (artificial intelligence) signal — A finding of a specific kind: a field, text block or manifest that states the picture was generated by a model. The report names both the signal and the exact location it was read from, such as
XMP DigitalSourceTypeorPNG tEXt "parameters". - Self-declared — Said by the file about itself in plain, unsigned metadata. Any program can write or erase it, so a self-declaration is evidence of what a tool wrote, not proof of what happened.
- Declared in Content Credentials — Said inside a signed C2PA manifest. If the signature verifies and the signer is trusted, the statement cannot have been altered since signing.
- Inconsistent — The verdict when parts of the metadata contradict each other, which is the fingerprint of a file that was stripped and then re-labelled by hand. See the findings on EXIF versus XMP below.
- Stripped — Metadata removed. Most social platforms and messaging apps do this on upload; so do "remove EXIF" tools. A stripped file cannot be judged from metadata at all.
- Re-labelled — Metadata written onto a file after its original metadata was removed, to make it look like something it is not. Usually detected as an inconsistency.
- Segment map — The table at the bottom of a JPEG, PNG or WebP report listing every block in the file in order, with its offset and length. Blocks that carry provenance information are marked.
- SHA-256 (Secure Hash Algorithm, 256-bit) — A cryptographic hash: a fixed-length fingerprint of the file's bytes. The report shows it so two people can confirm they are looking at the same file. Changing a single byte changes the whole hash.
Containers: how the bytes are laid out
- Container — The file format that wraps the picture data and its metadata: JPEG, PNG, WebP and so on. Each has its own way of holding metadata, which is why the same EXIF block sits in an "APP1 segment" in a JPEG and an "eXIf chunk" in a PNG.
- JPEG (Joint Photographic Experts Group) — The most common photo format, named after the committee that defined it. A JPEG is a sequence of segments, each introduced by a two-byte marker.
- SOI / EOI (Start Of Image / End Of Image) — The first and last markers of a JPEG. Data after EOI is ignored by viewers and is a classic hiding place.
- APPn segment (application segment n) — APP0 through APP15, where JPEG metadata lives. Which standard uses which number is convention, not enforced by the format.
- APP0 JFIF (JPEG File Interchange Format) — The basic JPEG header: version, pixel density, sometimes a thumbnail. Almost every JPEG has one. Carries no provenance.
- APP1 EXIF (Exchangeable Image File Format) — The segment that holds EXIF (see below). Cameras and phones write it.
- APP1 XMP (Extensible Metadata Platform) — The segment that holds XMP. A large XMP packet spills into APP1 XMP ext (extended XMP) segments that have to be reassembled.
- APP2 ICC (International Color Consortium) — The colour profile, split across several APP2 segments if large. Says how to interpret colour values, nothing about origin.
- APP2 MPF (Multi-Picture Format) — An index of extra images embedded in the same file, typically a large preview or a depth map from a phone. Some phones' metadata lives in here.
- APP11 (JPEG XT) — The segment number used by JPEG XT (JPEG eXTensions, the ISO/IEC 18477 family; IEC is the International Electrotechnical Commission, ISO's partner on joint standards) for boxed data. C2PA uses it too, so APP11 C2PA is the label for APP11 segments whose content is a C2PA JUMBF box, possibly split over several segments and reassembled by sequence number.
- APP13 Photoshop IRB (Image Resource Block) / IPTC (International Press Telecommunications Council) — Photoshop's resource blocks. Historically where IPTC caption and copyright fields were stored; Photoshop still writes them.
- APP14 Adobe — A small segment Adobe encoders write to describe the colour transform. Its presence tells you the file passed through an Adobe library at some point.
- COM (comment) — A free-text comment segment. Some generators write their parameters here.
- Scan data — The compressed pixels themselves, everything from the first SOS (Start Of Scan) marker to EOI.
- PNG (Portable Network Graphics) — A lossless format made of chunks: a four-letter type, a length, the data, and a CRC (cyclic redundancy check) checksum. Chunk names with a lowercase first letter are optional and may be dropped by any tool that does not understand them.
- PNG signature — The fixed eight bytes every PNG starts with.
- IHDR / IDAT / IEND (image header / image data / image end) — The mandatory chunks: header (dimensions, bit depth), image data, and end-of-file.
- tEXt / iTXt / zTXt — PNG text chunks: a keyword plus a value.
tEXtis Latin-1 (ISO 8859-1),iTXtis international text in UTF-8 (Unicode Transformation Format, 8-bit) and may be compressed,zTXtis zlib-compressed Latin-1. This is where Stable Diffusion, ComfyUI and NovelAI write their generation parameters, and where the AIGC label usually goes in a PNG. - eXIf — The PNG chunk standardised in 2017 for carrying an EXIF block. Older tools put EXIF in a text chunk instead.
- iCCP (ICC profile) — The PNG chunk for an ICC colour profile.
- caBX — The four-letter chunk type the C2PA specification registered for carrying a JUMBF box in a PNG. It is a chunk name, not an initialism with an official expansion. caBX C2PA in a report means the chunk was found and parsed as a manifest store.
- WebP — Google's image format, derived from the VP8 video codec. A WebP is a RIFF (Resource Interchange File Format) file: a header and a sequence of chunks with four-letter names. VP8 and VP8L (VP8 lossless) hold the image data; VP8X (VP8 extended) is the header that says which optional chunks follow. EXIF, XMP and ICCP (ICC profile) chunks carry those blocks; the C2PA chunk carries a JUMBF box.
- HEIC / AVIF / TIFF / GIF — Formats this site reads EXIF and XMP from but does not map segment by segment. HEIC (High Efficiency Image Container) and AVIF (AV1 Image File Format; AV1 is AOMedia Video 1, the codec it stores) are ISO base media file format containers, the same family as MP4 (MPEG-4 Part 14; MPEG is the Moving Picture Experts Group). TIFF (Tagged Image File Format) is the format EXIF itself is modelled on. GIF (Graphics Interchange Format) carries almost no metadata.
Read more: Where metadata lives in a file, Why metadata disappears.
Metadata standards
- Metadata — Data about the picture stored alongside the pixels: when it was taken, by which camera, with which settings, by which program it was last saved. None of it is needed to display the image, which is why it can be removed without visible change.
- EXIF (Exchangeable Image File Format) — The standard cameras and phones use to record capture details: Make and Model, exposure, lens, DateTimeOriginal, orientation, GPS, and Software (the last program that wrote the file). It is a binary structure borrowed from TIFF. Editors either preserve it, rewrite it, or drop it. Nothing in EXIF is signed.
- DateTimeOriginal — The EXIF capture timestamp, in local time with no zone. Compared against the XMP create date to detect a mismatch.
- Software — The EXIF tag naming the program that last wrote the file. A generator's name here is an AI signal; an editor's name is just an editor.
- XMP (Extensible Metadata Platform) — Adobe's metadata standard, written in XML (Extensible Markup Language) and now an ISO (International Organization for Standardization) standard, ISO 16684. It stores the same facts as EXIF plus editing information: CreatorTool (the program), CreateDate and ModifyDate, and the edit history. Text, unsigned, and rewritten by every Adobe product on save.
- CreatorTool — The XMP field naming the program that created the file. Compared against EXIF Software; the two usually agree on a file with an honest history.
- XMP History —
xmpMM:History(MM for Media Management), a list of edit events, each with a software agent, an action and a time. A file that claims derivation from another (DerivedFrom) but has no history is suspicious. - DerivedFrom — The XMP field pointing at the document this one was made from. Present on an exported edit; meaningless on a camera original.
- Document ID / Instance ID (identifier) — XMP identifiers Adobe products assign to a document and to each saved version of it. They let History entries be tied to specific saves.
- IPTC (International Press Telecommunications Council) — The news industry's metadata schema for photos: caption, credit, copyright, and since 2023 the DigitalSourceType field.
- DigitalSourceType — An IPTC field, stored in XMP, that states how the picture was produced. The value
trainedAlgorithmicMediameans "created by a trained AI model". Adobe Firefly, DALL·E and several others write it. It is the closest thing to an industry-standard AI flag in plain metadata, and it is still just text. - ICC (International Color Consortium) profile — A colour profile. Tells software how to convert the file's colour values for display. Says nothing about origin, though the profile's description can name the program that embedded it.
- GPS (Global Positioning System) — Location fields inside EXIF. Reported as a finding because a shared photo rarely needs to carry them.
Read more: EXIF basics, XMP and edit history, How metadata gets forged.
C2PA and Content Credentials
- C2PA (Coalition for Content Provenance and Authenticity) — An industry body (Adobe, Microsoft, Google, Sony, Nikon, Leica, OpenAI and others) and the name of the open technical specification it publishes for signed provenance data.
- CAI (Content Authenticity Initiative) — The Adobe-led community that promotes C2PA adoption and runs the public Verify site.
- Content Credentials — The consumer-facing name for C2PA data attached to a file. When a report says "Contains Content Credentials" it means a C2PA manifest store was found.
- Manifest — One signed record of provenance: who made this version, with what tool, what actions were taken, what it was derived from. A file edited several times by C2PA-aware tools carries several manifests.
- Manifest store — The container holding all of a file's manifests. Physically it is a JUMBF box in APP11, caBX or the WebP C2PA chunk.
- Active manifest — The most recent manifest, the one that describes the file as it is now. Only its hard binding is expected to match the current bytes; earlier manifests are covered as ingredients of later ones.
- Claim — The core of a manifest: a CBOR structure listing the assertions by hash, the claim generator, and a reference to the signature. The signature is computed over the claim's bytes.
- Claim generator — The software that produced the manifest, named in the claim. Reported as the tool.
- Assertion — A statement inside a manifest. Standard ones include c2pa.actions (what was done), c2pa.hash.data (the hard binding), c2pa.ingredient (what it was made from), and stds.schema-org.CreativeWork (author and copyright).
- Action — One entry in the actions assertion:
c2pa.created,c2pa.edited,c2pa.opened,c2pa.placed, and so on. A creation action with a digital source type oftrainedAlgorithmicMediais how a manifest declares AI generation;digitalCapturedeclares a camera capture. - Ingredient — An assertion recording another asset that went into this one, with its own manifest hash where it had one. Ingredients are how a chain of edits stays verifiable.
- JUMBF (JPEG Universal Metadata Box Format) — The box-structured binary container C2PA uses, defined in ISO/IEC 19566-5. Boxes nest: a superbox holds a description box (
jumd) and content boxes such ascbor,jsonorbidb(binary data box). - CBOR (Concise Binary Object Representation) — A compact binary encoding of JSON-like data, defined in RFC 8949. Claims and most assertions are CBOR.
- JSON (JavaScript Object Notation) — The plain-text data format that CBOR is the binary cousin of. Some assertions, and the AIGC label, are JSON.
- COSE (CBOR Object Signing and Encryption) / COSE_Sign1 — The signing format built on CBOR, defined in RFC 9052.
COSE_Sign1is the single-signer signature structure C2PA uses: protected headers (algorithm, certificate chain), the payload (the claim), and the signature bytes. - X.509 certificate — The standard format for a public-key certificate, named after the ITU-T (International Telecommunication Union, Telecommunication Standardization Sector) recommendation that defines it: a public key, the name of its owner, the name of the issuer that vouches for it, validity dates, and the issuer's signature. The signing certificate travels inside the COSE header as x5chain (X.509 chain).
- Certificate chain — The signing (leaf) certificate, the intermediate that issued it, and so on up to a root. Each link is checked by verifying one certificate's signature with the next one's key.
- Trust anchor — A certificate the verifier decides to trust without further proof. If the chain reaches one, the signer's identity is considered established.
- Trust list — The set of trust anchors. C2PA publishes an official list of certificate authorities and signers it has vetted. "Signature valid, signer unknown" means the maths checked out but the chain did not reach anything on the list, which is the case for a self-made certificate.
- Signature valid — The COSE signature over the claim verifies with the leaf certificate's key. Proves the manifest was not altered after signing. It does not by itself prove who signed.
- Hard binding — The hash in
c2pa.hash.data, computed over the file with the manifest store itself excluded. If it matches, the pixels were not changed after signing and this manifest belongs to this file. If the picture was re-encoded or edited by a tool without C2PA support, this check fails. - Soft binding — A binding that survives re-encoding, such as an invisible watermark or a perceptual fingerprint, used to look a manifest up when it was stripped from the file. This site does not evaluate soft bindings.
- Assertion hashes — Each assertion is hashed and the claim lists the hashes. Verifying them proves no assertion was swapped under a valid claim.
- Timestamp (sigTst, signature timestamp) — An optional RFC 3161 (Request for Comments 3161, the Internet standard for trusted timestamps) token from a time-stamping authority, proving the signature existed at a given time. Reported as present or absent; not verified in this version.
- Verification failed / partially verified — "Failed" means one of the four checks (signature, hard binding, assertion hashes, chain) came out negative. "Partially verified" means a check could not be completed, for example because a hash algorithm is unsupported, and the report says which.
- Verify site —
verify.contentauthenticity.org, the CAI's public checker. A useful second opinion, since it applies the same trust list this site does.
Read more: What is C2PA, How to verify C2PA.
Traces left by AI generators
- Generation parameters — The prompt, model, seed, sampler and settings a generator used, written into the file by tools that want the image to be reproducible. Their presence is a strong AI signal; their absence proves nothing.
- Stable Diffusion (SD) — The open-source family of image models. Its most common front-ends write parameters into PNG text. SDXL is Stable Diffusion XL, the larger 2023 model.
- Stable Diffusion WebUI (AUTOMATIC1111, A1111) — The classic web front-end, named after its author's handle; A1111 is the short form. Writes a
parameterstext chunk: the prompt, then aNegative prompt:line, thenSteps: ..., Sampler: ..., Model: .... The report extracts the model name when present. - ComfyUI (Comfy User Interface) — A node-graph front-end. Writes two text chunks:
prompt(the graph as JSON) andworkflow(the editor layout). - NovelAI — A hosted anime-focused generator. Writes
Software: NovelAIplus aCommentchunk with JSON parameters, and often the words "Stable Diffusion" in the description. - Midjourney — A hosted generator. Downloads carry XMP with the prompt in the description and a Job ID (a UUID, universally unique identifier) in a Midjourney-specific field; also a
Creatorfield naming the user. - DALL·E / OpenAI — OpenAI's image models; the name is a blend of the artist Dalí and the robot WALL·E, not an acronym. Recent outputs carry a C2PA manifest naming OpenAI and an actions assertion with
trainedAlgorithmicMedia; older DALL·E 3 files had only aDigitalSourceType. - Adobe Firefly — Adobe's generator. Writes a C2PA manifest and IPTC DigitalSourceType.
- Google Imagen / Gemini — Google's models. Outputs carry an invisible SynthID watermark and, on some surfaces, C2PA metadata or an IPTC flag.
- FLUX, Ideogram, Leonardo.Ai, Recraft, Krea, Runway, InvokeAI, Fooocus, Microsoft Designer, LiblibAI — Other generators and front-ends whose names, when found in any metadata field, are treated as a statement of AI origin.
- 通义万相 Tongyi Wanxiang, 即梦 Jimeng / 豆包 Doubao, 可灵 Kling, 文心一格 Yige, 混元 Hunyuan — Chinese generation services. Their names in metadata are AI signals, and since September 2025 their outputs are expected to carry the AIGC implicit label described below.
- Invisible watermark — A signal embedded in the pixels themselves rather than in metadata, designed to survive cropping, re-encoding and screenshots. SynthID is Google's; others exist. They need the vendor's detector and are not readable from metadata, so this site cannot see them.
Read more: Stable Diffusion metadata, Midjourney metadata, OpenAI image metadata, Invisible watermarks.
The Chinese AIGC labelling rules
- AIGC (AI-Generated Content) — The term Chinese regulation and industry use for text, images, audio and video produced by generative models.
- Labelling Measures — The Measures for Labelling AI-Generated Synthetic Content, issued by the CAC (Cyberspace Administration of China) together with three other regulators, in force since 1 September 2025. They oblige generation services to label outputs and distribution platforms to preserve and surface the labels.
- GB 45438-2025 — The mandatory national standard that specifies how to label: "Cybersecurity technology: Labelling method for AI-generated synthetic content". GB is short for Guobiao, "national standard", the prefix on every Chinese national standard. Took effect the same day as the Measures.
- TC260 (Technical Committee 260) — The National Information Security Standardization Technical Committee, which drafts the standards and publishes practice guides, including the one describing the metadata label.
- Explicit label — A label people can perceive: visible text or a badge on an image, an audible notice in audio.
- Implicit label — A label written into file metadata for machines to read. In practice a JSON object in an XMP field, a PNG text chunk or a JPEG comment.
Label: "AIGC"— The fixed first field of the implicit label. The report searches every text carrier in the file for a JSON object containing it.- ContentProducer — The name or code of the service that generated the content.
- ProduceID — The service's identifier for this particular piece of content.
- ContentPropagator / PropagateID — The platform that distributed the content and its identifier for it, filled in when a platform re-writes the label on upload.
- ReservedCode1 / ReservedCode2 — Fields the standard reserves for future use.
Read more: What the AIGC implicit label looks like.
Cryptography, briefly
- Hash — A one-way function that turns any data into a fixed-length fingerprint. Equal inputs give equal hashes; a changed input gives an unrelated hash. C2PA uses SHA-256 and relatives for every binding.
- Digital signature — A value computed from a hash of the data with a private key, checkable by anyone with the matching public key. Proves the data was not altered and was signed by the key's holder.
- Public key / private key — The two halves of a key pair. The private half signs and is kept secret; the public half verifies and is published inside the certificate.
- CA (certificate authority) — An organisation that issues certificates after checking the applicant's identity. A CA's root certificate is what trust lists contain.
- Self-signed certificate — A certificate signed with its own key. Anyone can make one in seconds, so it proves nothing about identity, only that the same key signed both the certificate and the data.
- RFC (Request for Comments) — The numbered documents in which Internet standards are published; RFC 3161 (timestamps), RFC 8949 (CBOR) and RFC 9052 (COSE) all appear on this page.
- TSA (time-stamping authority) — A service that signs a hash together with the current time, per RFC 3161, so a signature can be proven to predate a given moment.
- Validity period — The dates between which a certificate is meant to be used. A manifest signed with an expired certificate is reported; whether that matters depends on whether a timestamp proves it was signed while valid.