Skip to main content

Working with manifests


The concept of a manifest is central to how Content Credentials work.

A collection of manifests (known as a manifest store) is attached to an asset. Each manifest contains information about the provenance of the asset. Creating or editing an asset using a C2PA-compliant device or tool (for example Adobe Photoshop) adds a new manifest to the manifest store.

A manifest store can be linked to an asset in three ways:

  1. Directly embedded in the asset's metadata.
  2. In a sidecar file, a file with the same file name as the asset but with a .c2pa extension.
  3. In a remote URL, linked from the asset's metadata, as detailed in the C2PA specification. NOTE: A given asset can have a remote manifest store plus a local manifest store linked in one of the first two ways.

To determine if an asset has Content Credentials, the SDK checks for the presence of a manifest store (in the order shown above). So, for example to see if foo.jpg has Content Credentials, the SDK first checks if there's a manifest store in the file itself, then looks for a sidecar file (foo.c2pa in the same directory), and finally looks in the asset's metadata for a reference to a remote manifest store.

A remote manifest store can be provided for a given asset as well as an embedded or sidecar manifest store. In other words, an asset can have an embedded and a remote manifest store or a sidecar and a remote manifest store.


Currently, only Adobe has implemented a Content Credentials cloud service to provide access to remote manifest stores, but in theory anyone could do so to provide a publicly-accessible network location for manifests.

The manifests in the manifest store are not ordered, but the most-recently added manifest is the active manifest. The active manifest has content bindings that can be validated with the assetthat is, it's hashed with the asset to ensure its validity.

Binary versus JSON manifest

The manifest as described in the C2PA specification is a binary structure in JPEG universal metadata box format (JUMBF) that can include JSON and binary data for things like encryption keys and thumbnail images.

Because the binary structure is hard to understand and program to, the SDK defines a JSON manifest structure that's a declarative language for representing and creating a manifest in binary format. The JSON manifest is a human-readable format, a more abstract translation layer that's easier to understand than the binary format. The JSON format can describe everything in the underlying binary format except for blobs representing thumbnails and other binary data that are included by a structure called a resource reference.

The JSON structure describes all the things in a manifest, some of which can be binaries like thumbnails, which are referenced by a file path. Then when the SDK generates the binary manifest structure, it assembles all the JSON objects, resource references, and ingredients defined, and then converts them into different assertions and other objects as required.


The C2PA specification strongly recommends that a manifest signature contains a trusted time-stamp proving that the signature actually existed at a certain date. Specifically, it recommends using a Time-Stamp Authority (TSA) that complies with Internet X.509 Public Key Infrastructure Time-Stamp Protocol (RFC 3161) standard.


Manifests without time-stamps cease to be valid when the signing credential expires or is revoked.

An RFC 3161 time-stamp enables you to prove the existence of a particular piece of data at a particular time. Think of it as a notary service for data. You present a piece of data (in this case, the C2PA claim data structure) and the third-party TSA verifies that it saw that data at a time that can be audited and is independently verifiable.

The time-stamp is typically defined as part of the signing information. You can set this via the c2patool ta_url field or by using the API. The time-stamp then appears in the SignatureInfo JSON object when reading the manifest store.