How to Remove C2PA Content Credentials from Images

C2PA content credentials represent the most sophisticated metadata system ever deployed in digital imaging. Developed by the Coalition for Content Provenance and Authenticity -- a joint effort by Adobe, Microsoft, BBC, Arm, Intel, and Truepic -- C2PA embeds cryptographically signed provenance data directly into image files. A single C2PA manifest can identify the tool that created an image, the actions performed on it, the cryptographic chain of custody, and the digital signature of the issuing authority. For AI-generated images, C2PA is rapidly becoming the industry standard for disclosure. Adobe Firefly, DALL-E, and Google Imagen all embed C2PA manifests in their output.

But C2PA manifests are metadata. They live in the file structure, not in the pixels. And like all metadata, they can be removed. This guide explains exactly where C2PA data is stored across different image formats and why canvas redrawing is the only reliable method for complete removal.

What C2PA Content Credentials Contain

A C2PA manifest is a structured data record that follows the JUMBF (JPEG Universal Metadata Box Format) specification. Each manifest contains several components:

Claim: The core assertion about the image. This includes the assertion that the image was generated by a specific AI tool, the type of AI model used (identified by a C2PA digital source type URI), the timestamp of generation, and any additional metadata the tool provider chooses to include.

Claim signature: A cryptographic signature (typically ECDSA with a P-256 or P-384 curve) that verifies the claim was issued by the stated authority. The signature is generated using a private key held by the tool provider (e.g., Adobe, OpenAI) and can be verified using the corresponding public key embedded in a certificate chain.

Certificate chain: An X.509 certificate chain that links the signing key to a trusted root certificate authority. This allows verifiers to confirm that the signature is valid and was issued by a legitimate C2PA participant.

Ingredient references: If the image was derived from another image (e.g., an AI-generated image that was subsequently edited), the manifest may reference the C2PA manifest of the source image, creating a provenance chain.

Validation icon and manifest URL: Some implementations include a URL where the manifest can be verified online, and a visual icon or badge indicating that content credentials are present.

The manifest data is encoded using CBOR (Concise Binary Object Representation), a binary data format similar to JSON but more compact and efficient. CBOR encoding allows complex nested structures to be stored in a relatively small footprint, though C2PA manifests with full certificate chains can still reach 50 to 320 kilobytes.

Where C2PA Lives in Different Image Formats

C2PA content credentials are stored differently depending on the image format. Understanding these storage locations is essential for understanding why removal requires a comprehensive approach.

JPEG -- APP11 (JUMBF segment): In JPEG files, C2PA data is stored in an APP11 marker segment using the JUMBF box structure. The APP11 segment begins with the standard marker (0xFF 0xEB), followed by the segment length, and then a series of JUMBF boxes. Each box has a type code, a length, and a payload. The C2PA-specific boxes include jumd (JUMBF description box), c2pa (C2PA manifest box), and nested boxes for the claim, signature, and certificates.

The JPEG APP11 segment can be quite large -- a single C2PA manifest with a full certificate chain and multiple assertions typically occupies 80 to 200 KB within the JPEG file. Multiple manifests can coexist in a single JPEG (e.g., one from the AI tool and one from a subsequent editor), each in its own JUMBF box.

PNG -- caBX ancillary chunk: In PNG files, C2PA data is stored in a caBX ancillary chunk. The chunk follows standard PNG chunk structure: a four-character type code (caBX), a length field, the CBOR-encoded JUMBF payload, and a CRC checksum. The caBX chunk appears between the IHDR and IEND chunks, typically after the IDAT chunks.

The caBX chunk contains the same JUMBF box structure as JPEG's APP11 segment, with the same claim, signature, and certificate chain components. The only difference is the container: an APP11 segment in JPEG versus a caBX chunk in PNG.

WebP -- c2pa chunk: In WebP files, C2PA data is stored in a c2pa chunk within the RIFF container structure. The WebP RIFF format organizes data into chunks, and the c2pa chunk sits alongside other metadata chunks like EXIF and XMP. The payload is the same JUMBF/CBOR structure used in JPEG and PNG.

The JUMBF Box Structure in Detail

JUMBF (JPEG Universal Metadata Box Format) is the container format used by C2PA across all image formats. Understanding its structure helps clarify why C2PA removal must be thorough:

The top-level structure is a JUMBF superbox containing one or more content boxes. Each content box has:

• jumd (JUMBF Description Box): Specifies the content type (for C2PA, this is c2pa), the trigger (what causes the box to be processed), and the label (a unique identifier for this manifest).
• jumb (JUMBF Box): Contains the actual C2PA data, which is further divided into:
  • Claim box (c2pa.claim): The CBOR-encoded assertions about the image. This is the core data -- which tool generated it, what actions were performed, timestamps, and provenance references.
  • Signature box (c2pa.signature): The cryptographic signature over the claim, using COSE (CBOR Object Signing and Encryption) format. This typically contains an ECDSA signature with a SHA-256 or SHA-384 hash.
  • Certificate box (c2pa.certificates): The X.509 certificate chain that validates the signature. This is often the largest component, as it includes intermediate and root CA certificates.

The CBOR encoding used for the claim data is a binary format that represents data structures similar to JSON but with smaller size and faster parsing. CBOR supports maps (equivalent to JSON objects), arrays, text strings, byte strings, integers, and floating-point values. The C2PA specification defines a specific CBOR schema for its assertion structures.

Why Canvas Redrawing Is the Only Reliable Removal Method

Given the complexity of C2PA storage -- different locations in JPEG, PNG, and WebP; nested JUMBF box structures; CBOR encoding; multiple manifests -- you might consider targeted removal. Could you parse the file, locate the C2PA-specific segments, and remove only those?

Technically, yes. But targeted C2PA removal has serious reliability problems:

Format-specific parsing required: You need separate parsers for JPEG APP11, PNG caBX, and WebP c2pa chunks. Each has different header structures, length calculations, and checksum requirements. A parser that handles JPEG will not handle PNG, and vice versa.

C2PA can be embedded in XMP: Some implementations embed C2PA data within XMP packets stored in APP1 (JPEG) or iTXt (PNG) chunks, rather than in dedicated C2PA segments. This means you cannot simply remove the C2PA-specific container -- you must also parse XMP for embedded C2PA references.

JUMBF box nesting makes partial removal dangerous: JUMBF boxes can be nested to arbitrary depth. Removing a C2PA box from the middle of a JUMBF superbox without correctly recalculating lengths and offsets can corrupt the file or leave orphaned data.

Certificate chains can span multiple segments: In JPEG files, a large C2PA manifest may be split across multiple APP11 segments. You must reassemble them before parsing and removal, adding complexity.

Canvas redrawing sidesteps all of these issues. When you draw an image onto an HTML5 Canvas and export it as a new file, the browser generates a clean file with no APP11 segments, no caBX chunks, and no c2pa RIFF chunks. The C2PA data simply does not exist in the new file. There is nothing to parse, nothing to miss, and nothing to corrupt.

The process is the same regardless of format:

1. Load the image (JPEG, PNG, or WebP) into the browser
2. Decode the pixel data and draw it onto a Canvas
3. Export the Canvas as a new image file in your chosen format
4. The output contains zero C2PA data -- no manifests, no signatures, no certificates

What Happens After C2PA Removal

Once C2PA content credentials are removed, several things change:

Content credential verification fails. Anyone attempting to verify the image using a C2PA-aware tool (such as Adobe's Content Credentials verifier or the C2PA open-source validator) will receive a result indicating that no content credentials are present. The image will appear to have no provenance information.

AI detection via C2PA becomes impossible. Tools that rely on C2PA manifests to identify AI-generated content will not flag the image. This includes platform-level detection systems used by social media networks and stock photography sites that check for C2PA data during upload.

Other metadata indicators may still exist. C2PA removal alone does not remove EXIF, XMP, or IPTC metadata. The Software field in EXIF may still identify an AI tool. XMP packets may still contain generation parameters. For comprehensive cleaning, all metadata types must be removed together -- which canvas redrawing does in a single pass.

Steganographic watermarks are unaffected. If the AI tool also embedded a steganographic watermark (such as Google's SynthID), this watermark survives canvas redrawing because it is encoded in the pixel data, not the file structure. C2PA removal addresses metadata-level provenance only.

FAQ

Is it legal to remove C2PA content credentials?

C2PA metadata is stored as standard file metadata and can be removed like any other metadata. As of early 2026, no jurisdiction has enacted a law specifically prohibiting the removal of C2PA content credentials from image files. However, the EU AI Act includes requirements for AI-generated content to be labeled as such. If you are removing C2PA data from AI-generated images to circumvent disclosure requirements in regulated contexts, you should consult legal counsel. For personal privacy and general metadata management, removal is legal.

Can C2PA manifests be added back after removal?

Yes. C2PA manifests can be added to any image file using the C2PA SDK or compatible tools. However, you cannot forge a valid C2PA manifest from a specific tool provider (such as Adobe or OpenAI) without access to their private signing keys. You could create a self-signed manifest, but it would not carry the same trust as a manifest signed by a recognized C2PA authority.

How can I tell if an image has C2PA data before removing it?

You can use RemoveAI Image to inspect any image file. The tool automatically detects and displays C2PA content credentials including the generator, version, actions, digital source type, and signature information. This gives you full visibility into what provenance data is embedded before you decide to remove it.

---

C2PA content credentials are the most advanced metadata system in digital imaging, but they are still metadata -- stored in the file structure, not the pixels. RemoveAI Image detects and removes C2PA manifests from JPEG, PNG, and WebP files using canvas redrawing, along with EXIF, XMP, IPTC, and GPS data. Everything runs locally in your browser with no uploads. Inspect your images, see what is embedded, and clean them completely.