Standards 9 min read 30 September 2026

PDF/A Explained: The Right Format for Long-Term Document Storage

PDF/A is the ISO standard that defines which PDF features are safe for long-term archiving. This guide explains the PDF/A profiles (PDF/A-1 through PDF/A-4), what each restricts and why, and how to verify that a document actually conforms before committing it to an archive.

PDF/A is the ISO standard for PDF documents intended for long-term archiving. Its full name — PDF for Archiving — describes its purpose: a version of PDF stripped of features that could prevent a document from being correctly rendered decades from now, regardless of what software or operating system is used. The core philosophy of PDF/A is self-containment. A conformant PDF/A file must carry everything needed to reproduce it exactly as intended: all fonts must be embedded, all colour spaces must be explicitly defined, external content references are prohibited, and encryption (which could prevent access) is banned. The result is a larger file than a typical PDF, but one that can be opened and rendered correctly by any conformant viewer, now or in the future. PDF/A was published as ISO 19005 in four parts between 2005 and 2020 — PDF/A-1, PDF/A-2, PDF/A-3, and PDF/A-4 — each expanding the capabilities available while maintaining the archival self-containment principle. Choosing the right profile for a given use case requires understanding what each profile permits and prohibits.

Why PDF/A exists: the archival problem

The problem PDF/A addresses is simple: digital formats rot. Software changes, features are deprecated, external dependencies go offline, and what was perfectly readable in one decade may be inaccessible in the next. Standard PDFs can reference external content — fonts loaded from the operating system, JavaScript that calls external services, colour profiles linked by URL. They can be encrypted in ways that could become inaccessible if password management fails. They can use features like multimedia embedding that depend on specific viewer plugins that may no longer exist. For organisations with retention obligations — government agencies, financial institutions, law firms, healthcare providers, research archives — the risk of document inaccessibility is a compliance and operational problem. A court record sealed in 2024 may need to be produced in 2074. A research dataset archived today may need to be reproduced in fifty years. PDF/A was developed by the PDF Association and standardised by ISO to give archivists a well-defined, verifiable subset of PDF that eliminates the features most likely to cause future access problems. Conformance can be validated programmatically against the specification, making it auditable in a way that a general PDF is not.

PDF/A profiles: -1, -2, -3, and -4

PDF/A has evolved through four main versions, each based on a different version of the core PDF specification: PDF/A-1 (ISO 19005-1:2005) — Based on PDF 1.4. The most restrictive profile. Prohibits encryption, JavaScript, external content references, transparency (alpha blending), and embedded files. Two conformance levels: /B (basic — visual reproducibility only) and /A (accessible — requires tagged PDF for full accessibility). Still widely required by archiving systems that were designed when PDF/A-1 was the only option. PDF/A-2 (ISO 19005-2:2011) — Based on PDF 1.7. Adds support for JPEG 2000 compression, transparency and layers, digital signatures using PDF advanced electronic signatures (PAdES), and embedding of other PDF/A files (not arbitrary files). Conformance levels: /B, /A, and /U (Unicode — requires complete Unicode character mapping). PDF/A-3 (ISO 19005-3:2012) — Based on PDF 1.7. Identical to PDF/A-2 except it permits embedding of any file type as an attachment (not just other PDF/A files). This capability underpins ZUGFeRD and Factur-X e-invoicing, where an XML invoice is embedded inside a PDF/A-3 container. Three conformance levels: /B, /A, /U. PDF/A-4 (ISO 19005-4:2020) — Based on PDF 2.0 (ISO 32000-2:2017). Drops the /B and /A level distinction; all PDF/A-4 documents require Unicode mapping (/U equivalent). Adds /E (engineering) level for technical documents. Supports PDF 2.0 features including new structure element types and updated encryption options. This is the current standard for new archiving implementations.

What PDF/A prohibits and why

Understanding why PDF/A prohibits specific features illuminates its design logic: No encryption — An encrypted PDF that cannot be decrypted is inaccessible. Password management can fail over decades — passwords are forgotten, staff turn over, key management systems are retired. PDF/A prohibits encryption entirely to guarantee future access. No external content references — Standard PDFs can reference fonts, colour profiles, and multimedia from outside the file. If those external resources become unavailable (a font licence expires, a URL goes dead), the PDF cannot be correctly rendered. PDF/A requires all such resources to be fully embedded. Fonts must be fully embedded — A PDF without embedded fonts relies on the viewer substituting a matching system font. Substitution changes character metrics, line breaks, and potentially character rendering, destroying the document's visual integrity. PDF/A requires all fonts to be embedded, including their /ToUnicode mappings for character extraction. No JavaScript — JavaScript in PDFs can call external services, modify content dynamically, and behave differently across viewers. Archival documents must be static and deterministic. JavaScript is prohibited entirely. Colour spaces must be device-independent — Device-dependent colour (RGB values relative to a monitor's gamut) reproduces differently on different devices. PDF/A requires either embedded ICC colour profiles or use of specific PDF device-independent colour spaces, ensuring consistent colour reproduction.

Validating PDF/A conformance

Claiming a PDF is PDF/A compliant is not the same as it actually being conformant. Many tools produce PDFs with a PDF/A metadata declaration but structural issues that violate the specification. The two main open-source validation tools are: veraPDF — The industry-standard open-source PDF/A validator, developed under an Open Preservation Foundation project with EU PREFORMA funding. Supports PDF/A-1 through PDF/A-4 validation. Command-line and GUI interfaces. Used by digital preservation services worldwide. PDF Tools Validator — A commercial validator with batch processing capabilities. A valid PDF/A file will pass validation with zero errors. Common validation failures in practice: fonts not embedded, missing /ToUnicode mappings, external colour space references, transparency in PDF/A-1 documents, and missing or incorrect metadata declarations. For organisations with large archival collections, running batch validation with veraPDF on intake is best practice — catching non-conformant documents at the point of deposit rather than discovering them years later.

When to use PDF/A — and when not to

PDF/A is the right choice for: government and legal records, medical records, financial audit trails, research data, contracts and agreements, and any document that must be legally or operationally accessible for more than a few years. It is not appropriate for: interactive forms intended for user completion (form features may be restricted), documents with multimedia content, documents that need encryption for security compliance, or working documents that will be frequently edited (the self-containment requirements make iterative editing cumbersome). A common workflow is to maintain working documents as standard PDFs during their active lifecycle, then convert to PDF/A for archival at the point of finalisation. Some document management systems do this conversion automatically as part of the record closure process. For e-invoicing under EU mandates, PDF/A-3 with an embedded XML attachment is the required format for ZUGFeRD and Factur-X compliant invoices — an archival format serving a practical data exchange function simultaneously.

PDF/A gives archivists a precise, verifiable commitment: a document that conforms to the standard will be renderable by any conformant viewer, without external dependencies, for as long as the standard is maintained. Choose the profile based on your PDF version baseline (PDF/A-1 for maximum compatibility, PDF/A-4 for new implementations on modern toolchains) and validate conformance programmatically rather than relying on creation tool claims.

Frequently asked questions

What is the difference between PDF and PDF/A?

PDF is the general format; PDF/A is a restricted subset designed for long-term archiving. PDF/A prohibits features that could prevent future rendering — encryption, external references, JavaScript, and unembedded fonts — and requires all resources (fonts, colour profiles) to be self-contained in the file. A standard PDF may use all these features freely.

Which PDF/A profile should I use?

For new implementations: PDF/A-4 (based on PDF 2.0) if your toolchain supports it; PDF/A-2 otherwise. For maximum compatibility with older archival systems that only accept PDF/A-1: use PDF/A-1b (visual reproducibility) or PDF/A-1a (accessibility, requires tagged PDF). For e-invoicing (ZUGFeRD, Factur-X): PDF/A-3 is required because it permits arbitrary file attachments.

Can I convert a regular PDF to PDF/A?

Yes, but conversion may fail or require changes to the source document. Tools like Ghostscript, veraPDF, and commercial tools like Callas pdfaPilot can convert standard PDFs to PDF/A, embedding missing fonts and stripping prohibited features. The result must be validated to confirm conformance — creation tool claims are not sufficient.

Does PDF/A require tagged PDF?

It depends on the conformance level. PDF/A /B (basic) levels require only visual reproducibility — no tagging. PDF/A /A (accessible) levels require full Tagged PDF structure conforming to PDF/UA accessibility requirements. PDF/A-4 requires Unicode mapping for all text but has no /B level — all documents must have /U Unicode support at minimum.

Can a PDF/A document contain a digital signature?

PDF/A-1 prohibits digital signatures. PDF/A-2 and later permit digital signatures using the PAdES (PDF Advanced Electronic Signatures) profile defined by ETSI EN 319 102. The signature must use algorithms that are expected to remain valid over the archival period — currently SHA-256 or better with RSA-2048 or ECC.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Sign PDF Redact PDF Fill PDF form Open editor