PDF/A

PDF/A is the ISO-standardized, self-contained subset of PDF for long-term archiving, first published as ISO 19005-1 in 2005, requiring embedded fonts and prohibiting encryption or external dependencies.

Extension

.pdf

Full name

Portable Document Format / Archive

Introduced

2005

Vendor

ISO (based on Adobe's PDF)

What is inside the container

A PDF/A file uses the same underlying container as regular PDF but with mandatory constraints: all fonts must be embedded (no relying on fonts installed on the viewing system), no encryption, no audio/video or executable JavaScript, and no references to external content — everything needed to render the document identically must be inside the file itself. Multiple conformance parts exist (PDF/A-1 through PDF/A-4), each with basic "b" and accessibility-focused "a"/"u" levels, and PDF/A-3 specifically permits embedding arbitrary non-PDF source files (like the original XML invoice data behind a rendered PDF).

How to open it

Windows / macOS Adobe Acrobat Reader opens and can validate PDF/A conformance

Cross-platform viewer Any standard PDF viewer displays PDF/A like a normal PDF — Preview on macOS, browser built-in PDF viewers

Validation veraPDF, the industry-standard open-source validator, checks strict PDF/A conformance

DAM / records management Ghostscript or Acrobat Preflight for automated PDF-to-PDF/A conversion on ingest

For archives

PDF/A is exactly the format a DAM's records-management or long-term-preservation module should convert regular PDFs to before archival, since it eliminates the two biggest risks to future document readability: missing fonts and encryption locks. A DAM handling regulatory, legal, or historical document collections should validate incoming PDF/A files with a proper conformance checker (not just trust the file extension) and, where the source is a standard PDF, run it through an automated PDF/A conversion step at ingest rather than leaving preservation decisions to whoever uploaded the file.

PDF/A was published as ISO 19005-1 in 2005, developed through a collaboration between the AIIM standards association and the U.S. National Association for Information Destruction, building on Adobe’s PDF 1.4 specification but adding a set of hard constraints specifically aimed at long-term readability rather than everyday document exchange. The core insight behind the standard is self-containment: a document that depends on an external font, an internet-hosted resource, or an encryption key that might not exist in twenty years is a document that can silently become unreadable, so PDF/A simply prohibits those dependencies.

The standard has expanded since 2005 to keep pace with newer PDF capabilities: PDF/A-2 (2011) added support for JPEG 2000 compression and PDF/A file attachments based on the newer PDF 1.7/ISO 32000-1 base, and PDF/A-3 (2012) went further by allowing arbitrary non-PDF files to be embedded — for example, keeping the original structured XML or spreadsheet data alongside a rendered invoice PDF, a feature widely used in e-invoicing standards. Each part defines conformance levels, with the basic “b” level guaranteeing visual reproducibility and the “a” (accessible) level adding requirements for structured, extractable text.

Part	Published	Based on	Key addition
PDF/A-1	2005	PDF 1.4	Original archival subset
PDF/A-2	2011	PDF 1.7 / ISO 32000-1	JPEG 2000 support, PDF/A attachments
PDF/A-3	2012	PDF 1.7	Allows embedding arbitrary non-PDF files (e.g. source XML)

For a DAM built around compliance-sensitive or long-lived document collections — contracts, government filings, historical scans — PDF/A is the format the archival tier should standardize on rather than plain PDF. Regular PDFs commonly reference system fonts or carry password encryption, either of which can make a document unreadable or inaccessible years later in ways that are invisible at the moment of upload; converting to validated PDF/A at ingest catches those problems while the source is still available to fix them.

Frequently asked

What's the actual difference between a regular PDF and a PDF/A file?

PDF/A is a constrained subset of PDF that requires all fonts to be embedded, prohibits encryption and password protection, forbids external references and executable content like JavaScript, and requires everything needed to render the document to be self-contained within the file. A regular PDF has none of those guarantees.

How can a DAM verify that a file claiming to be PDF/A actually conforms to the standard?

By running it through a dedicated conformance validator like veraPDF, the open-source tool widely used as the industry reference implementation — a file simply having a PDF/A-flagged XMP metadata tag doesn't guarantee it actually meets every structural requirement of the standard.

Should a DAM convert every incoming PDF to PDF/A automatically?

For compliance-sensitive or long-term archival collections, yes — automated conversion at ingest (via Ghostscript, Acrobat Preflight, or a similar tool) catches font-embedding and encryption problems while the source document is still available, rather than discovering the document is unreadable years later.

What's the difference between PDF/A-1, PDF/A-2, and PDF/A-3?

PDF/A-1 (2005) is the original standard based on PDF 1.4; PDF/A-2 (2011) added JPEG 2000 image compression and attachment support based on the newer PDF 1.7; PDF/A-3 (2012) further allows embedding arbitrary non-PDF files, such as the original source data behind a generated document, which is why it's common in e-invoicing.

Does PDF/A support scanned documents and OCR text the same way regular PDF does?

Yes — PDF/A can hold a scanned page image with an invisible OCR text layer underneath, the same technique regular PDF uses, and this combination is common in document-archive DAMs where both visual fidelity and searchable text matter.

Can a PDF/A file be password-protected for a DAM enforcing access control?

No — PDF/A explicitly prohibits encryption, since a password or key required to open the file is exactly the kind of external dependency that can be lost over time. Access control for PDF/A documents needs to happen at the DAM's permission layer, not inside the file itself.

Is PDF/A a good format for interactive forms or documents with embedded video?

No — PDF/A prohibits multimedia content and restricts interactive form fields to those that render statically without requiring executable code, since the standard prioritizes guaranteed long-term rendering over interactivity.

Why do government and legal document repositories specifically require PDF/A?

Because records-retention regulations in many jurisdictions require documents to remain readable and unaltered for years or decades, and PDF/A's self-contained, encryption-free, dependency-free design is specifically engineered to meet that requirement in a way ordinary PDF, with its optional fonts and encryption, cannot guarantee.

Sources

ISO 19005-1:2005, the first part of the PDF/A standard, specifies how to constrain PDF 1.4 for long-term preservation, prohibiting font linking, encryption, and other features unsuitable for archiving. checked 2026-08-07 — ISO — ISO 19005-1:2005