C2PA can associate Content Credentials with a wide range of digital assets, but the question "Does C2PA support this file format?" does not have a one-word answer. A format may have a normative embedding method in the C2PA specification, yet a particular SDK may only read it, another product may not write it, and a downstream platform may strip the embedded Manifest Store during processing.
The file extension is only the beginning. A production system has to distinguish the media or document container, the codec or content carried inside it, the C2PA hard-binding method, where the Manifest Store is placed, whether remote manifests are allowed, and whether every tool in the delivery chain preserves the result.
C2PA 2.4 defines format-specific embedding for common images, audio, video, documents, fonts, HTML, and text. It also allows Manifest Stores to remain external when embedding is unavailable, impractical, or inappropriate. This means C2PA can cover more assets than the list of formats with native embedding rules, but discovery and interoperability become more dependent on the surrounding workflow. [1]
What "supported" means in C2PA
A reliable support statement should answer four separate questions. Collapsing them into one checkbox is the source of many interoperability failures.
Layer | Question | Why it matters |
|---|---|---|
Specification support | Does C2PA 2.4 define how the Manifest Store is embedded or referenced and how the asset is hard-bound? | This determines whether independent implementations have a common technical contract. |
Implementation support | Can the selected SDK or product read, write, update, and validate that exact format variant? | A specification may cover more formats than one library release implements. |
Workflow preservation | Do editors, optimizers, transcoders, CDNs, and publishing platforms preserve or reissue the credential? | A correctly signed input can lose or invalidate provenance later in the pipeline. |
Operational support | Can remote resources be fetched safely, trust data be updated, and failures be monitored? | A format may parse successfully while the surrounding provenance service is unavailable or unsafe. |
The most precise language is therefore not "Unfurled supports MP4" but something like: "This release can read, validate, and write C2PA Manifest Stores in non-fragmented MP4 files using the BMFF embedding and hash model; fragmented and live workflows are tested separately." The statement names the container, operation, and limitation.
The format families at a glance
C2PA groups formats by their internal structure. Several familiar extensions share one embedding method because they use the same container family.
Family | Common examples | Primary C2PA association |
|---|---|---|
Format-specific image structures | JPEG, PNG, GIF, TIFF/DNG, JPEG XL | A format-specific marker, chunk, tag, extension block, or JUMBF box. |
RIFF-based media | WebP, WAV, BWF, AVI | A RIFF chunk identified as C2PA. |
BMFF-based media | MP4, M4A, M4S, MOV, HEIF/HEIC, AVIF | One or more C2PA uuid boxes plus BMFF-aware hashing. |
ID3 or Ogg audio | MP3, some FLAC workflows, Ogg Vorbis | An ID3 GEOB object or a dedicated Ogg logical bitstream. |
Documents | Embedded file streams at document or object level. | |
ZIP-based packages | DOCX, XLSX, PPTX, EPUB, ODT, ODS, ODP, OpenXPS | META-INF/content_credential.c2pa plus collection hashing. |
Web and text | HTML, Markdown, source code, YAML, plain text | Inline, referenced, comment/front-matter, or Unicode-based association. |
Fonts and multi-part assets | OpenType/TrueType; MPF, Ultra HDR, Motion Photo | A C2PA font table or a primary-part Manifest Store plus multi-asset hashing. |
The family is often more important than the filename suffix. AAC audio inside an M4A file is handled as BMFF; a raw AAC stream is not the same asset structure. AV1 video in MP4 is a BMFF asset, while AV1 video in WebM is a different container for which C2PA 2.4 does not define the same native embedding method.
Image formats
Format or family | Embedding method in C2PA 2.4 | Important caveat |
|---|---|---|
JPEG | APP11 marker segments carrying the Manifest Store. | A large store can require multiple contiguous APP11 segments. Re-encoding or metadata cleanup can remove them. |
PNG | A private ancillary caBX chunk, preferably before image-data chunks. | The chunk is marked not safe to copy, so generic PNG transformations may discard it. |
TIFF, TIFF/EP, DNG, and related RAW | TIFF tag 52545 in the final main-IFD position, with one Manifest Store for the asset. | TIFF indirection and multi-page structures require careful offset handling; the store should be placed near the end for updates. |
WebP | A C2PA chunk in the RIFF container. | The format is supported through RIFF rules, not through a generic image-metadata rule. |
GIF | A dedicated C2PA Application Extension block split into GIF-sized data sub-blocks. | The block has a defined position before the first image descriptor; optimizers may remove application extensions. |
SVG | Base64 Manifest Store inside a c2pa:manifest element in SVG metadata. | C2PA prefers an external manifest. XML reserialization and sanitization can change or remove the association. |
JPEG XL | A top-level JUMBF box in the box-structured form of JPEG XL. | A raw JPEG XL codestream cannot contain an embedded C2PA Manifest Store. |
HEIF, HEIC, and AVIF | C2PA uuid boxes using the BMFF method. | Support depends on the BMFF container implementation, not merely the image codec or extension. |
MPF, Ultra HDR, and Motion Photo | JPEG-compatible embedding for the primary part plus multi-asset hashing when parts need separate integrity. | These are multi-part assets; optional or secondary parts need explicit treatment. |
BMP and other formats without defined embedding | Use an external Manifest Store and an appropriate hard binding. | The asset needs a reliable discovery mechanism; an adjacent .c2pa file alone may not survive distribution. |
JPEG and PNG are common starting points because their embedding methods are well specified and widely used, but neither guarantees survival through an image pipeline. A service that decodes a JPEG, resizes the pixels, and writes a fresh JPEG has created a new asset representation. It must either preserve and correctly update provenance or issue a new manifest for the rendition. Copying the old bytes into the new file would not make the old hard binding valid.
JPEG XL deserves a format-variant warning. The box form can carry JUMBF and therefore an embedded Manifest Store; a codestream-only file cannot. A product claiming JPEG XL support should state whether it can distinguish and handle both forms. The same discipline applies to multi-part JPEG-derived formats: the primary JPEG may be valid while an attached depth map, alternate image, or motion component requires a multi-asset model. [2]
Audio formats
Audio support depends heavily on the container. The same codec name can appear in several different structures, and those structures do not share one universal embedding rule.
Format or family | C2PA method | Important caveat |
|---|---|---|
WAV and BWF | A C2PA chunk in the RIFF container. | Audio editors and broadcast systems must preserve or intentionally rewrite the RIFF chunk. |
MP3 | The Manifest Store is carried as a GEOB object in an ID3v2-compatible file. | ID3-stripping tools, tag editors, and distribution services may remove it. |
FLAC | C2PA 2.4 lists an ID3v2-compatible embedding path. | This is not the same as a native FLAC-container method; test the exact file structure and toolchain. |
Ogg Vorbis | A dedicated Ogg logical bitstream beginning with the C2PA identifier. | The method is new enough that implementation interoperability should be tested explicitly. |
AAC and ALAC in M4A/MP4 | The BMFF uuid-box method. | The support applies to BMFF-packaged audio, not automatically to raw AAC/ADTS or every proprietary wrapper. |
Other or raw audio | External Manifest Store when no native embedding contract applies. | Discovery, availability, and transformation monitoring become part of the product design. |
A useful support matrix should therefore identify both the codec and the container. "AAC supported" is ambiguous; "AAC in M4A using the BMFF method" is testable. Likewise, a file named .flac may be a native FLAC stream with metadata blocks rather than an ID3v2-compatible structure. The C2PA specification is the format contract, but the implementation has to inspect the bytes rather than trusting the suffix.
Video, timed media, and live streams
MP4, MOV, fragmented MP4, M4S segments, downloadable M4A audio, HEIF, and AVIF are handled through the ISO Base Media File Format family. C2PA uses a dedicated uuid box and a BMFF-specific hard-binding model. The structure can also include auxiliary Merkle information so large media can be validated in subsets rather than downloaded and hashed as one monolithic object.
For ordinary files, the Manifest Store box has defined placement relative to the ftyp, mdat, and moov boxes. Update manifests can be appended in a separate update box without moving the data covered by the earlier hard binding. A writer must understand box sizes, offsets, and fragmentation; simply appending arbitrary bytes to an MP4 is not a compliant implementation.
C2PA also defines live-video architectures for segmented BMFF delivery. One approach associates manifests with segments; another uses signed session information and verifiable segment records. Adaptive streaming systems that generate renditions on demand may need to generate and sign each deterministic output or cache manifests for the exact renditions they serve. This is operationally different from signing one source MP4. [4]
AVI is covered through the RIFF method. WebM and MPEG transport streams do not receive an equivalent native embedding section in C2PA 2.4, so an implementation should not infer support merely because the contained video codec is familiar. An external Manifest Store or a C2PA-aware repackaging workflow may still be used.
PDF and document formats
PDF receives special treatment because it is both a document container and an incrementally updateable format. C2PA Manifest Stores are embedded as associated file streams with the application/c2pa media type. A manifest can apply to the whole document or to a specific object, such as an image, form object, font, or structured content element.
A PDF can contain multiple Manifest Stores across incremental updates. The most recent applicable store becomes the active entry point, while validators process the related stores as one logical provenance history. Coordination with native PDF signatures is essential: the space and byte ranges for a PDF signature need to be planned so adding it does not invalidate the C2PA binding, and a certifying signature may restrict which later changes are allowed.
ZIP-based document packages
Many document and publication formats are ZIP archives with a prescribed internal layout. C2PA 2.4 defines one family-level method for EPUB, Office Open XML, OpenDocument, OpenXPS, and other ZIP-based packages. The Manifest Store is placed at META-INF/content_credential.c2pa, stored without compression or encryption, while a collection data hash protects the other package members and the ZIP Central Directory.
This family includes familiar files such as DOCX, XLSX, PPTX, ODT, ODS, ODP, and EPUB. The format-level support does not mean that Microsoft Word, Excel, PowerPoint, LibreOffice, or every EPUB reader will preserve or display the credential. It means independent C2PA implementations have a defined location and hashing model. Native EPUB or OOXML digital signatures must be applied in the correct order relative to the C2PA Manifest Store. [3]
Document family | C2PA placement | Operational concern |
|---|---|---|
Associated embedded file stream; document-level or object-level. | Incremental updates and native PDF signatures change ordering and validation rules. | |
OOXML | META-INF/content_credential.c2pa inside the ZIP package. | Applications may rewrite the package; native XML signature precedes C2PA insertion. |
OpenDocument | The same ZIP-family placement and collection hash. | Editors may normalize package members or regenerate the archive. |
EPUB | The same ZIP-family placement and collection hash. | EPUB signing and encrypted content require deliberate ordering and testing. |
OpenXPS | The same ZIP-family approach through OPC. | Native package signatures and viewer support vary. |
Generic ZIP-based formats | Potentially the ZIP-family method when the package structure is understood. | Do not assume every .zip archive is semantically one asset or that every tool will preserve META-INF. |
HTML, structured text, and unstructured text
HTML
HTML can contain one inline Manifest Store in a script element with type application/c2pa, or reference one external store through a link element with rel="c2pa-manifest". C2PA 2.4 prefers the external link approach. In either case, the hard binding is calculated over the stored byte representation of the HTML document.
That byte-level rule has a major consequence: a CMS, template engine, CDN, minifier, sanitizer, or browser-side build tool that changes whitespace, attribute order, quotation style, or encoding has changed the asset. The final manifest should be generated after the last deterministic serialization step, and the published bytes should be monitored rather than assuming logically equivalent HTML will retain the same binding.
Structured text
Structured text formats with comments or front matter can use a visible ASCII-armour-style block that either contains a data URI for the Manifest Store or points to an external store. The method applies to source code, YAML, TOML, INI, Markdown, AsciiDoc, LaTeX, and comparable text formats when no more specific C2PA embedding method exists.
The manifest block can appear in a comment or a front-matter section. This preserves human readability and avoids special Unicode requirements, but it depends on the toolchain preserving that block. Formatters, compilers, documentation generators, package managers, and minifiers may strip comments or normalize line endings. Hashing uses exact bytes outside the excluded manifest block, so the writer and validator must agree on placement and line-ending behavior.
Unstructured text
For text intended to survive copy and paste when ordinary file metadata is unavailable, C2PA 2.4 defines an optional wrapper encoded with Unicode variation selectors. The visible text is normalized to Unicode NFC and hashed after the wrapper bytes are excluded. The specification says this approach should be used only when no other embedding method is feasible and notes that it remains under review.
Plain text support should therefore be presented as an emerging interoperability feature, not a reason to embed invisible data into every text field. Systems need to consider normalization, editor behavior, truncation, copy-paste fidelity, accessibility, moderation, and user expectations. CSV is specifically unsuitable for the generic structured-text method because it lacks a standard comment or front-matter convention; an external Manifest Store is the safer pattern. [5]
Fonts
Open Font Format and OpenType-style fonts may carry a C2PA table containing an embedded Manifest Store, a URI for a remote store, or both. This makes it possible to associate provenance with font binaries and potentially describe creation, foundry identity, transformations, or licensing-related assertions.
The table definition in C2PA 2.4 is explicitly preliminary and is not yet part of the underlying Open Font Format or OpenType standards. A product should therefore treat font support as a controlled interoperability profile, test how font-subsetting and webfont conversion affect the table, and avoid claiming universal support across TTF, OTF, WOFF, and WOFF2 without format-specific evidence.
External Manifest Stores broaden format coverage
Native embedding is not a prerequisite for C2PA provenance. The specification allows a Manifest Store to be stored externally when embedding is technically impossible, impractical because the credential is large, or inappropriate because the original asset should not be modified. The store is served with the application/c2pa media type and must still contain a hard binding to the asset.
A validator may discover an external store through an HTTP Link header, an XMP dcterms:provenance reference, the C2PA font table, an HTML link element, a structured-text reference block, a same-path .c2pa resource, or another application-specific resolver. Finding a candidate store is not enough; the validator must confirm that its hard binding describes the exact asset being evaluated. [6]
External storage introduces dependencies that embedded credentials avoid: the location must remain available, access controls must permit retrieval, redirects and remote content must be handled safely, and the association has to survive when the asset moves to another host. Durable Content Credentials can add fingerprint or watermark recovery, but that is a discovery layer rather than a replacement for hard-binding validation.
The hard-binding method changes with the format
C2PA does not hash every asset in exactly the same way. The hard-binding assertion is selected to fit the structure of the asset and to exclude the Manifest Store without leaving unsafe gaps.
Binding model | Typical use | What implementers must get right |
|---|---|---|
Data hash | Byte-oriented files, HTML, text, PDF, TIFF, and other formats with defined exclusions. | Exact byte ranges, exclusions, final serialization, and no post-signing mutation. |
General box hash | Structured files such as JPEG, PNG, GIF, and other box-like assets. | Correct parsing, box order, salting where required, and narrowly scoped exclusions. |
BMFF hash and Merkle data | MP4, M4A, MOV, HEIF, AVIF, fragmented and large timed media. | Box semantics, offsets, media subsets, auxiliary data, and streaming behavior. |
Collection data hash | ZIP-based packages and logical collections. | Every included member, package directory integrity, URI safety, and deterministic packaging. |
Multi-asset hash | MPF, Ultra HDR, Motion Photo, and assets composed of separately addressable parts. | Complete part coverage, non-overlap, part order, optional-part policy, and per-part hard bindings. |
This is why format support belongs in a dedicated media layer rather than a generic "append metadata" function. A secure writer needs a parser that understands the container, a deterministic serializer, and test vectors for malformed, adversarial, and boundary-case files.
Specification support is not product support
A C2PA implementation can support different operations for the same format. A browser library might read and validate JPEG and PNG but not write them. A server SDK might sign MP4 but not produce live-stream credentials. A desktop editor might preserve an existing manifest when saving TIFF but remove it when exporting WebP. These are different capabilities and should be documented separately.
For each format or family, maintain a versioned matrix with at least the following columns:
- Detect and locate embedded Manifest Stores.
- Retrieve and validate external Manifest Stores.
- Read and normalize validation results.
- Create a new standard manifest.
- Create an update manifest where the format permits the required placement.
- Preserve or intentionally replace existing provenance during transformation.
- Handle ingredients, multi-part assets, and object-level manifests.
- Round-trip through the actual production applications, CDNs, and transcoders.
- Reject malformed, oversized, recursive, or hostile inputs safely.
Pin the SDK and specification versions in that matrix. A format added to C2PA 2.4 does not appear automatically in an older deployed binary, and a new library release may read a format before its writer is considered production ready. The final authority is a conformance and round-trip test against the exact build being shipped.
How to design a production format strategy
- Inventory the real outputs, not only the source files. Record the container, codec, profile, packaging variant, maximum size, encryption state, and whether assets are streamed or downloaded.
- Choose the canonical signing point after all content-changing and byte-changing transformations that should be covered by the credential.
- Prefer the format-specific C2PA embedding method when it is stable and preserved by the delivery chain. Use external manifests when embedding is unsupported, too large, or likely to be removed.
- Verify the completed output independently. Do not assume a successful signing API call produced a valid asset.
- Test every downstream transformation: image resizing, video transcoding, document editing, archive rewriting, HTML formatting, CDN optimization, and metadata sanitization.
- Measure preservation and validation by format, product version, and delivery path. Alert when a pipeline begins stripping or invalidating credentials.
- Document unsupported variants explicitly. "JPEG XL box form only" and "AAC in BMFF only" are useful limits; a broad unsupported claim such as "all images and video" is not.
- Retain an external evidence record for signing, validation, trust, and publication events even when the Manifest Store is embedded in the asset.
Three practical support decisions
A photo API producing JPEG and WebP renditions
Sign the final JPEG with the JPEG embedding method. When the service generates a WebP rendition, treat it as a new asset representation and issue a new standard manifest using the RIFF method, preserving the JPEG as a parent ingredient. Test the image CDN to confirm it does not remove the WebP C2PA chunk. If the CDN cannot preserve it, publish an external store and add durable recovery where appropriate.
An enterprise report delivered as DOCX and PDF
The DOCX uses the ZIP-package method and stores the Manifest Store under META-INF. The exported PDF receives its own document-level manifest because it is a different asset. If the PDF also carries a native PDF signature, reserve and order the signature operations according to the PDF rules. Do not copy the DOCX hard binding into the PDF.
A video platform serving adaptive streams
The mezzanine MP4, each downloadable rendition, and each live or segmented stream are distinct assets. The platform can sign the final MP4 renditions using BMFF rules and adopt the C2PA live-video architecture for segments. A credential embedded only in the mezzanine does not automatically describe the bytes delivered to viewers.
Common misunderstandings
Misunderstanding | More accurate interpretation |
|---|---|
"The specification lists the format, so every C2PA tool supports it." | The specification defines interoperability rules; each implementation may support a subset of read, write, update, and streaming operations. |
"If two files use the same codec, they use the same C2PA method." | The container usually determines placement and hashing. AAC in M4A is not the same structure as raw AAC. |
"Metadata-preserving means the credential remains valid." | A transformation can preserve the Manifest Store while changing protected content, producing a hard-binding failure. |
"An external Manifest Store is weaker by definition." | It can be cryptographically valid and trusted, but availability and discovery become external dependencies. |
"Plain text and source code are now universally safe to sign." | The 2.4 text methods depend on exact normalization and toolchain behavior; unstructured text remains an emerging method. |
"PDF and DOCX work like JPEG metadata." | PDF incremental updates and ZIP-package hashing require document-specific processing and signature ordering. |
"A successful upload proves the platform preserved C2PA." | The published output must be fetched and validated after every transformation and delivery step. |
"No native embedding method means C2PA cannot apply." | An external Manifest Store can be used if it remains discoverable and its hard binding validates against the asset. |
The simplest mental model
- The specification defines where a Manifest Store belongs and how it binds to each supported format family.
- The implementation determines which formats it can actually read, write, update, and validate.
- The workflow determines whether the credential survives or is correctly reissued after transformation.
- The container matters as much as the extension or codec.
- An external Manifest Store can extend C2PA to assets without a practical native embedding location.
- A format claim is credible only when it names the exact variant, operations, library version, and tested delivery path.
C2PA 2.4 has moved far beyond photographs. Its format model now reaches audio, video, streaming media, documents, package formats, fonts, HTML, source files, and text. The useful engineering question is no longer simply whether a file can carry a Content Credential. It is whether the complete system can create the right binding, preserve the credential through the real workflow, retrieve any external resources safely, and present a reproducible validation result at the point where the asset is actually consumed.
Sources and notes
[1] C2PA Technical Specification 2.4, "Supported Formats". Normative index of format families and their embedding sections.
[2] C2PA Technical Specification 2.4, "Embedding manifests into non-BMFF-based assets". JPEG, PNG, SVG, ID3, Ogg Vorbis, TIFF/DNG, RIFF, GIF, JPEG XL, and the preliminary font table.
[3] C2PA Technical Specification 2.4, "Embedding manifests into PDFs", "Embedding manifests into ZIP-based formats". Document-level and object-level PDF manifests, incremental updates, collection hashing, package placement, and native-signature ordering.
[4] C2PA Technical Specification 2.4, "Embedding manifests into BMFF-based assets", "Live Video". MP4/M4A/M4S, MOV, HEIF/HEIC, AVIF, fragmented media, Merkle data, and live-segment architectures.
[5] C2PA Technical Specification 2.4, "Embedding Manifests into HTML", "Unstructured Text", "Structured Text". Inline and referenced web manifests, byte-level HTML binding, Unicode text wrappers, and comment/front-matter association for source and markup formats.
[6] C2PA Technical Specification 2.4, "External Manifests", "Embedding manifests in multi-part assets". application/c2pa storage, reference-based discovery, and primary-part handling for assets composed of multiple parts.