PDF/A Explained: The Archival Standard That Makes Documents Self-Contained

Key takeaways

• PDF/A embeds everything the document needs to render — fonts, color profiles, metadata — and prohibits anything that might stop working in the future
• The four main levels are PDF/A-1, PDF/A-2, PDF/A-3, and PDF/A-4, each permitting progressively more features
• PDF/A-3 allows embedding arbitrary file attachments inside the PDF, making it useful for e-invoicing standards like ZUGFeRD and Factur-X
• Not every document needs PDF/A — it's for documents you genuinely need to read unchanged in 10, 20, or 50 years

Most PDFs are built to work now. They link to fonts loaded from a CDN, reference external stylesheets, and assume the viewer will have access to the software that created them. For a file you’re sending today and will never look at again, that’s fine. For a legal contract, a medical record, a financial statement, or a government filing that might need to be read identically in 20 years, it’s a problem.

PDF/A (the “A” stands for archiving) is the ISO standard that solves this. It defines a subset of the PDF format specifically designed for documents that need to remain exactly as created, regardless of what software or hardware views them in the future.

What PDF/A actually does

The central requirement of PDF/A is self-containment. A conforming PDF/A document must include everything required to render it correctly without accessing any external resources.

Fonts must be embedded. Every font used in the document — including subsets — must be embedded in the file. Documents that reference system fonts or link to font servers will fail PDF/A validation because those resources may not be available in the future.

Color must be device-independent. All colors must use a color space that’s defined by an embedded ICC profile or by the PDF/A specification itself. Device-dependent color spaces (like generic “RGB” without a profile) are prohibited because the same RGB values look different on different screens.

Metadata must be present and conformant. PDF/A requires XMP (Extensible Metadata Platform) metadata with specific fields about the document. This metadata is what allows archival systems to identify, index, and validate the document.

Encryption is prohibited. Encrypting a PDF/A document would prevent future access if the key or software becomes unavailable.

JavaScript and executable content are prohibited. Anything that could change the document’s appearance or behavior based on execution state is excluded. This includes JavaScript, audio, video, 3D content, and embedded executables.

External references are prohibited. No links to external resources — no web fonts, no referenced images hosted elsewhere, nothing that requires network access to render correctly.

The four levels

PDF/A isn’t a single specification — it has evolved through several versions with different feature sets.

PDF/A-1 (ISO 19005-1, 2005): The original standard, based on PDF 1.4. Most restrictive. Widely supported. Two conformance levels: 1a (accessible, full logical structure) and 1b (basic visual reproduction). Best choice for maximum compatibility with older validation tools.

PDF/A-2 (ISO 19005-2, 2011): Based on PDF 1.7. Adds support for transparency effects, layers, JPEG 2000 compression, and embedding of other PDF/A files as attachments. More flexible for complex documents while maintaining archival requirements.

PDF/A-3 (ISO 19005-3, 2012): Adds the ability to embed arbitrary file formats as attachments. This makes PDF/A-3 the basis for several e-invoicing standards: ZUGFeRD, Factur-X, and similar formats embed a machine-readable XML invoice inside a human-readable PDF/A-3 document.

PDF/A-4 (ISO 19005-4, 2020): Based on PDF 2.0. The newest standard. Eliminates the older conformance level complexity in favor of a cleaner structure. Adds support for digital signatures compliant with PAdES (PDF Advanced Electronic Signatures).

When you actually need PDF/A

PDF/A is not the right format for every document. The restrictions it imposes — no encryption, no JavaScript, font embedding — add file size and constrain what the document can do. For most shared documents, these trade-offs aren’t worth it.

Use PDF/A when you have a genuine long-term archival requirement:

• Legal and compliance documents that must be producible in their original form for audits, litigation, or regulatory review
• Government filings where regulations mandate PDF/A (common in European public sector contexts)
• Medical records subject to long-term retention requirements
• Financial statements that may need to be examined years later
• E-invoicing where PDF/A-3 is the required format (ZUGFeRD, Factur-X)
• Academic and research archives maintaining a permanent record

For an email attachment, a work-in-progress document, or a file you’ll look at once and discard, PDF/A adds overhead without benefit.

Validating a PDF/A document

Creating a file with a .pdf extension and embedding fonts doesn’t make it PDF/A — conformance requires validation against the ISO specification. A document that fails validation may render incorrectly or be rejected by archival systems.

Several validators can check PDF/A conformance:

• veraPDF (open-source, widely used) validates against all PDF/A levels and provides detailed reports on any violations
• Adobe Acrobat Pro includes a preflight tool with PDF/A profiles
• PDF/A-specific conversion tools typically validate output as part of the conversion process

Common validation failures include: system fonts not embedded, color spaces without ICC profiles, missing XMP metadata fields, and JavaScript remnants from interactive forms.

Converting existing PDFs to PDF/A

Not every PDF can be converted to PDF/A without changes. Documents that rely on features the standard prohibits — JavaScript forms, encrypted content, external resource links — require those features to be removed first.

For straightforward documents (reports, contracts, plain invoices), conversion usually succeeds. For interactive or encrypted documents, conversion requires removing the non-conformant features, which may change the document’s behavior.

PDF Editor’s PDF/A conversion handles font embedding, color space normalization, and XMP metadata insertion automatically — the most common sources of conversion failure. For documents with more complex features, the tool identifies what prevents conformance and what would need to change.

---

PDF/A is a pragmatic standard: it trades flexibility for permanence. For documents that genuinely need to be readable decades from now, it’s the right trade. For everything else, it’s overhead you don’t need.