Standards 11 min read 21 October 2026

PDF Long-Term Archiving: PDF/A Standards, Migration Strategies, and Real-World Deployment

Organisations that must retain documents for decades face specific PDF challenges: format obsolescence, dependency on proprietary software, and metadata loss. This guide covers the PDF/A standard family (PDF/A-1 through PDF/A-4), migration from older PDF versions, validation with veraPDF, and operational archiving policies.

Organisations that must retain documents for years or decades face a challenge that does not exist for short-lived documents: the technology used to create and view PDFs today may not exist in its current form in thirty years. Proprietary features, embedded dependencies, and format complexity can all make documents inaccessible over time — even if the file bytes are perfectly preserved. PDF/A was designed to solve this problem. It is a family of ISO standards that restrict PDF to a subset of features that ensures self-containment and long-term renderability: all fonts must be embedded, colour must be device-independent or ICC-profiled, JavaScript and external dependencies are prohibited, and metadata must follow standard conventions. This guide covers the PDF/A standard family from PDF/A-1 through PDF/A-4, the technical requirements of each, validation with veraPDF, and the operational archiving strategies used by national archives, financial institutions, and healthcare organisations.

The PDF/A standard family: from -1 to -4

The PDF/A standards form a progression, each based on a newer PDF version and adding new capabilities: PDF/A-1 (ISO 19005-1:2005) — Based on PDF 1.4. The most restrictive profile: - No encryption - No JavaScript - No transparency (no semi-transparent objects, blend modes, or soft masks) - No embedded files (no file attachments) - No audio/video - All fonts fully embedded - Colour spaces must be DeviceGray, DeviceRGB, DeviceCMYK, or ICC-based — no device-independent calibrated spaces - XMP metadata required in a specific schema Conformance levels: PDF/A-1a (full structural accessibility including tagged PDF) and PDF/A-1b (visual appearance preservation only — no tagging required). PDF/A-2 (ISO 19005-2:2011) — Based on PDF 1.7. Adds: - JPEG2000 compression - Transparency and layers (optional content groups — OCGs) - Embedded fonts may use CFF (Compact Font Format) subsetting - Embedded PDF/A-compliant files (but not arbitrary file types) - OpenType fonts Conformance levels: PDF/A-2a (tagged), PDF/A-2b (visual), PDF/A-2u (Unicode-compliant — like /b but with ToUnicode CMap required). PDF/A-3 (ISO 19005-3:2012) — Based on PDF 1.7. Identical to PDF/A-2 except: - Embedded files of any type are permitted (via the /AF associated files mechanism). This enables hybrid document workflows: ZUGFeRD e-invoices, medical records with HL7 data, research papers with embedded datasets. Same conformance levels as PDF/A-2. PDF/A-4 (ISO 19005-4:2020) — Based on PDF 2.0. The first PDF/A standard on the modern specification: - Removes the /a, /b, /u conformance level distinction — replaced by PDF/A-4 (based on PDF 2.0 generally), PDF/A-4f (includes arbitrary embedded files, like PDF/A-3), and PDF/A-4e (for engineering/technical documents including embedded 3D). - Supports PDF 2.0 encryption (AES-256-GCM) - Supports PDF 2.0 structure elements (/Aside, /FENote, etc.) - Associated files can be at the object level (not just document level)

Validation with veraPDF and PAC

Before committing documents to long-term storage, validate that they meet the claimed PDF/A conformance level. Unchecked PDF/A claims in metadata are not uncommon — a PDF may declare itself PDF/A-2b in its XMP metadata while containing features that violate the standard. veraPDF — The open-source, community-maintained PDF/A validator. It is the most comprehensive and trusted PDF/A validation tool available: - Command-line: verapdf --flavour 2b input.pdf (validates as PDF/A-2b) - Batch validation: verapdf --flavour 1b --format mrr *.pdf > report.xml - Available at verapdf.org - Supports all PDF/A conformance levels including PDF/A-4 PAC 2024 — The PDF Accessibility Checker also validates PDF/A conformance, particularly when PDF/A-1a or PDF/A-2a (tagged) is being claimed. Windows only; GUI-based. Useful for confirming accessibility-compliant archiving. Common validation failures: - Font not embedded (or subset prefix missing in PDF/A-1) - Non-RGB/non-CMYK colour space without ICC profile (DeviceN, Separation without alternate) - Transparency present in PDF/A-1 output - Missing or incorrect XMP metadata schema (dc:title, dc:creator, xmp:CreateDate required) - Non-PDF/A embedded file (PDF/A-2 restriction — only PDF/A files may be embedded; PDF/A-3 removes this restriction) - /JavaScript or /Launch actions present

Operational archiving strategies

Technical PDF/A compliance is necessary but not sufficient for a working long-term archiving programme. Operational considerations: Conversion vs. native creation — Converting existing PDFs to PDF/A-2b (using Ghostscript, callas pdfaPilot, or Adobe Acrobat Pro) is the fastest way to build a compliant archive but may alter the document (fonts substituted, transparency flattened, colour converted). Creating PDF/A natively in authoring workflows (Word with PDF/A export, InDesign PDF/A export, pdf-lib with compliance settings) preserves the original intent better. Tiered archiving — Not all documents require PDF/A-1 (the strictest profile). A common tier structure: - Permanent records (contracts, deeds, medical records, legal filings): PDF/A-1a or PDF/A-2a with full tagging - Long-term records (15–30 years; financial statements, HR records): PDF/A-2b - Hybrid data archives (e-invoices, research data): PDF/A-3b or PDF/A-4f OAIS and preservation metadata — The OAIS (Open Archival Information System) reference model (ISO 14721) is the framework used by national archives and research data repositories. An OAIS-compliant archive wraps archived content in an Archival Information Package (AIP) with provenance, fixity (checksums), and description metadata. PDF/A provides the file format; OAIS provides the package structure and management policy. Format migration — Even PDF/A may need to be migrated in future decades if the PDF format itself becomes obsolete. Migration policies should specify: trigger conditions (lack of viewer support, community obsolescence declaration), migration pathways (to a successor format), and verification procedures (before discarding originals).

Frequently asked questions

What is the difference between PDF/A-2a and PDF/A-2b?

Both PDF/A-2a and PDF/A-2b require the same baseline constraints (fonts embedded, colours device-independent or ICC-based, no JavaScript, no external dependencies). The difference is structural accessibility: PDF/A-2a requires that the document be tagged — with a complete structure tree mapping to ISO 32000 standard structure element types — so that the document's logical reading order and structure (headings, paragraphs, lists, tables, figures) are machine-readable. PDF/A-2b only requires visual fidelity — the document must render correctly, but no logical structure is required. PDF/A-2u requires Unicode mapping for all text (ToUnicode CMaps) so that text can be extracted and searched reliably, but does not require the full tagging of 2a. For maximum accessibility and long-term data quality, PDF/A-2a is the gold standard. For ease of implementation, PDF/A-2b is more achievable.

Can I use Ghostscript to convert PDFs to PDF/A?

Yes, Ghostscript can convert PDFs to PDF/A-1b or PDF/A-2b. The basic command: gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dPDFA=2 -dPDFACompatibilityPolicy=1 -sColorConversionStrategy=UseDeviceIndependentColor -sOutputFile=output_pdfa.pdf input.pdf. The -dPDFA=1 or -dPDFA=2 flag sets the conformance level. The -dPDFACompatibilityPolicy=1 flag tells Ghostscript to attempt conversion rather than fail on non-conforming features. Important: always validate the output with veraPDF after Ghostscript conversion — Ghostscript does not guarantee full PDF/A conformance. Common issues: it may not embed all fonts correctly for non-standard characters; it converts transparency by flattening (required for PDF/A-1); colour conversion may shift colours if ICC profiles are not supplied. For production archiving, commercial tools (callas pdfaPilot, Acrobat Pro) provide more reliable and audited conversion.

How long does PDF/A actually keep documents accessible?

PDF/A is designed to ensure that documents can be rendered correctly for the very long term — the ISO standard is explicitly intended for "decades or centuries". The key architectural decisions that support this: (1) Self-containment — all required resources (fonts, colour profiles) are embedded in the file; no external dependencies. (2) No proprietary extensions — all features used must be part of the ISO standard. (3) XMP metadata — standardised machine-readable metadata allows archive systems to manage documents without opening them. (4) Restricted feature set — by prohibiting complex features (JavaScript, transparency in PDF/A-1), the standard reduces the risk of rendering differences across implementations. In practice, the PDF format has a massive installed base that incentivises ongoing support — but ultimate long-term accessibility depends on the archiving organisation's migration policy, format monitoring, and willingness to convert to successor formats when needed.

Try it yourself

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

Edit PDF Compress PDF Protect PDF Open editor