An image file from a modern camera or editor can carry four overlapping kinds of metadata. EXIF records how the picture was taken. IPTC records what it shows and who owns it. XMP is a flexible container that carries IPTC fields, editing history, and almost anything else. C2PA, marketed as Content Credentials, is a signed provenance record that can repeat some of the same information but makes it tamper-evident.
The practical difference is trust. EXIF, IPTC, and XMP are unsigned: any tool can write any value, and nothing in the file records that it was changed. C2PA binds its statements to the file's bytes with a cryptographic signature, so a change after signing is detectable. None of the four is guaranteed to survive a trip through the internet. This page compares them side by side; the reading image metadata page covers what the individual fields reveal.
At a glance
| EXIF | IPTC | XMP | C2PA | |
|---|---|---|---|---|
| Purpose | Capture settings and device data | Editorial description and rights | General-purpose, extensible metadata | Signed provenance and edit history |
| Maintained by | CIPA with JEITA (Japan) | International Press Telecommunications Council | Adobe; ISO 16684-1 | Coalition for Content Provenance and Authenticity |
| Encoding | TIFF-style binary tags | Legacy binary IIM records, or XMP properties | RDF/XML text packet | CBOR and JSON assertions in JUMBF boxes |
| Location in a JPEG | APP1 segment | APP13 (IIM, inside Photoshop resources) or APP1 (as XMP) | APP1 segment; also .xmp sidecar files | APP11 segments; also .c2pa sidecar or remote URL |
| Signed | No | No | No | Yes, X.509 certificate |
| Edits detectable | No | No | No | Yes, the manifest fails validation |
| Typical writers | Cameras, phones | Photographers, agencies, newsroom systems | Editing and asset-management software | C2PA-enabled cameras, phones, editors, AI generators |
| Read with | ExifTool, most image viewers | ExifTool, photo-management software | ExifTool, Adobe apps | c2patool, Verify, Adobe Inspect; ExifTool (raw data) |
EXIF
The Exchangeable image file format dates to the mid-1990s and is now maintained jointly by the Camera and Imaging Products Association (CIPA) and the Japan Electronics and Information Technology Industries Association (JEITA). The current version, Exif 3.0, was published in 2023 and added a UTF-8 text type, so fields like Artist and Copyright are no longer restricted to ASCII.
EXIF stores numbered tags in TIFF-style image file directories: make and model, exposure time, aperture, ISO, focal length, lens, timestamps, GPS coordinates, orientation, often an embedded thumbnail, and a manufacturer-specific MakerNote. In a JPEG it sits in an APP1 segment; PNG has an eXIf chunk; HEIF stores it as a metadata item. It is written automatically by the device, which makes it the richest source of capture detail and the one with the most privacy exposure, especially GPS.
IPTC
The International Press Telecommunications Council maintains the IPTC Photo Metadata Standard, the vocabulary newsrooms and agencies use for captions, creator, credit line, copyright notice, usage terms, keywords, and location. It exists in two encodings:
- IIM (Information Interchange Model), the original binary format from the early 1990s. In a JPEG, IIM records sit inside the Photoshop image-resource block in an APP13 segment. ExifTool's own documentation describes it as an older format being phased out in favour of XMP.
- IPTC Core and IPTC Extension, the same concepts expressed as XMP properties. This is where new fields are added.
IPTC matters for provenance because of its Digital Source Type property, a controlled vocabulary with values such as digitalCapture and trainedAlgorithmicMedia that labels how an image was made. The C2PA specification uses the same vocabulary, and several platforms read the unsigned IPTC version to apply AI labels. The 2025.1 release, published in November 2025, added properties for the AI system used and the prompt.
XMP
The Extensible Metadata Platform was introduced by Adobe in 2001 and standardized as ISO 16684-1. An XMP packet is RDF/XML text organized into namespaces: Dublin Core (dc:), Adobe's basic and media-management schemas, Photoshop and Camera Raw settings, IPTC Core and Extension, and any custom namespace an application defines. In a JPEG it lives in its own APP1 segment; for raw camera files, editors often write it to a separate .xmp sidecar instead.
XMP's media-management namespace can hold a document ID, an instance ID, and a history of save and edit events. This looks like provenance and is sometimes read as such, but it is unsigned and freely editable, so it is a record of what software chose to write, not evidence of what happened. The C2PA specification uses XMP in one small way: when a manifest is stored outside the file, it recommends a dcterms:provenance entry in the XMP pointing to where the manifest can be found.
C2PA
C2PA is different in kind. A C2PA manifest is a set of assertions (actions, ingredients, digital source type, creator information) gathered into a claim that is signed with an X.509 certificate. A hard binding, a hash over the file's bytes excluding the manifest itself, ties the signature to this exact file. The structure is stored in JUMBF boxes (ISO/IEC 19566-5): APP11 segments in a JPEG, a caBX chunk in a PNG, and format-specific boxes elsewhere. The manifest structure page covers the details.
C2PA does not replace the older formats. A C2PA-enabled camera still writes EXIF, and an editor still writes XMP. The specification defines a c2pa.metadata assertion that can carry an allowed subset of EXIF, IPTC, XMP, and Schema.org fields inside the signed manifest; a validator rejects fields outside that list. When capture details matter, the version inside the manifest is the one the signer vouched for. The copies in the ordinary metadata segments may have been edited since.
What survives common workflows
Survival depends on the specific software, its settings, and the version in use, so treat the table below as typical behaviour, not a guarantee. Test your own pipeline.
| Workflow | EXIF, IPTC, XMP | C2PA |
|---|---|---|
| Metadata edited with ExifTool or similar | Changed silently, with no trace | Manifest still present but fails validation (assertion.dataHash.mismatch) |
| Re-saved in an editor without C2PA support | Usually preserved | Dropped, or carried along stale and then invalid |
| Edited and exported in a C2PA-enabled editor with credentials turned on | Usually preserved | New signed manifest, with the previous one as an ingredient |
| "Export for web" with metadata excluded | Removed | Removed unless the export attaches a new credential |
| Upload to a social platform | Most platforms strip most fields; some keep selected rights fields | Usually stripped; a few platforms preserve or display it |
| Messaging-app recompression | Usually stripped | Usually stripped |
| Screenshot | Gone; the new file gets the screenshotting device's metadata | Gone; only watermark or fingerprint recovery can link it back |
Platform behaviour changes often and is tracked on the platform policies page. The one case where C2PA has an answer the others lack is the last row: a manifest that used a soft binding, meaning an invisible watermark or a fingerprint, can sometimes be recovered from a repository after the file itself has been stripped. See durable Content Credentials and hard vs. soft bindings.
Reading each with ExifTool
ExifTool reads all four. Group names select a family of tags; -G1 prints the specific group of each tag, -a keeps duplicates (the same field often appears in EXIF, IPTC, and XMP at once), and -s prints tag names instead of descriptions.
# everything, labelled by group
exiftool -a -G1 -s photo.jpg
# EXIF only
exiftool -EXIF:all photo.jpg
# IPTC IIM (legacy binary records)
exiftool -IPTC:all photo.jpg
# IPTC Core and Extension (stored as XMP)
exiftool -XMP-iptcCore:all -XMP-iptcExt:all -G1 photo.jpg
# all XMP, grouped by namespace
exiftool -XMP:all -G1 photo.jpg
# the raw XMP packet
exiftool -xmp -b photo.jpg > photo.xmpExifTool also parses C2PA's JUMBF data from JPEG, PNG, TIFF-based, QuickTime-based (including HEIF and MP4), RIFF-based, PDF, SVG, and GIF files. Its tag documentation suggests these arguments for reading it:
exiftool -jumbf:all -G3 -b -j -u -struct photo.jpgExifTool shows the contents of a manifest, but it does not validate signatures, check hashes, or apply a trust list. A manifest that has been tampered with looks the same in ExifTool as an intact one. To validate, use c2patool or one of the tools on the viewing Content Credentials page:
c2patool photo.jpg --infoExifTool can also delete C2PA data from supported formats with -jumbf:all=, and this is why a missing manifest proves nothing. Stripping is the subject of the next page.
Which one to trust for what
- Camera settings and capture time: EXIF is the usual source, but treat it as a claim. Prefer the values inside a valid C2PA manifest when there is one.
- Caption, credit, and rights: IPTC is the working standard. Check it against the publisher's own record.
- Edit history: XMP history shows what software chose to record. A C2PA actions assertion shows what a signer stood behind.
- Whether AI was involved: an IPTC Digital Source Type in plain XMP is a useful signal but trivially removed or forged. The same value in a signed manifest from a trusted signer carries more weight. Absence of either tells you nothing; see AI image detection.