PDF/A: The ISO Standard for Long-Term Document Archival

PDF/A: The ISO Standard for Long-Term Document Archival

PDF/A is a family of ISO standards that define a subset of PDF specifically designed for long-term archival. Where regular PDF allows external dependencies (linked fonts, external media, JavaScript, encryption), PDF/A mandates self-containment: everything needed to render the document identically must be embedded within the file itself. Understanding PDF/A's requirements, conformance levels, and use cases is essential for anyone working with legal documents, government records, medical records, or any content requiring decades of reliable access.

Why PDF/A? The Problem with Regular PDF

A standard PDF file can reference:

• External fonts: A file saying "use Times New Roman 12pt" relies on that font being installed on the viewing system
• External color profiles: Color rendering may differ between systems
• Encryption: An encrypted PDF cannot be read by a future viewer without the key
• JavaScript: Interactive elements may not function in future viewers
• Linked media: External images, audio, or video files that may not exist in the future
• Proprietary extensions: Vendor-specific PDF features that may not be implemented by future software

PDF/A prohibits all of these, ensuring the document will render identically on any compliant viewer in the year 2100.

PDF/A Conformance Levels and Parts

PDF/A has evolved through multiple ISO standards:

PDF/A-1 (ISO 19005-1:2005)

PDF/A-2 (ISO 19005-2:2011)

Based on PDF 1.7. Adds:

• JPEG 2000 image compression support
• Transparent graphics (PDF 1.4+)
• Optional content (layers)
• Embedding of PDF/A-1 and PDF/A-2 files
• Improved color management

PDF/A-3 (ISO 19005-3:2012)

Identical to PDF/A-2 except it allows embedding of any file type (not just other PDF/A files). This enables embedding source data (XML, CSV, original Word document) alongside the rendered PDF — critical for e-invoicing (ZUGFeRD, Factur-X standards).

PDF/A-4 (ISO 19005-4:2020)

Based on PDF 2.0. Replaces A/B/U levels with:

• PDF/A-4: basic requirements
• PDF/A-4e: engineering (allows embedded 3D models in U3D/PRC format)
• PDF/A-4f: allows arbitrary file attachments (like PDF/A-3)

What PDF/A Prohibits

What PDF/A Requires

The XMP metadata requirement is particularly important: PDF/A mandates a pdfaid:conformance and pdfaid:part property in the XMP:

<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
  <pdfaid:part>2</pdfaid:part>
  <pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>

Without this, a file is not self-identifying as PDF/A even if it meets all other requirements.

Creating PDF/A Files

From Microsoft Office

Word/Excel/PowerPoint:
File → Save As → PDF
Options → ISO 19005-1 compliant (PDF/A) ✓

LibreOffice

# Export as PDF/A-1b
libreoffice --headless --convert-to \
  "pdf:writer_pdf_Export:{SelectPdfVersion:{type:long,value:1}}" \
  document.docx

Or via GUI: File → Export as PDF → General tab → PDF/A-1b ✓

Ghostscript (convert any PDF to PDF/A)

# Convert to PDF/A-2b
gs -dPDFA=2 -dBATCH -dNOPAUSE \
   -sProcessColorModel=DeviceRGB \
   -sDEVICE=pdfwrite \
   -dPDFACompatibilityPolicy=1 \
   -sOutputFile=output_pdfa2b.pdf \
   /usr/share/ghostscript/PDFA_def.ps \
   input.pdf

# Convert to PDF/A-1b
gs -dPDFA=1 -dBATCH -dNOPAUSE \
   -sProcessColorModel=DeviceRGB \
   -sDEVICE=pdfwrite \
   -dPDFACompatibilityPolicy=1 \
   -sOutputFile=output_pdfa1b.pdf \
   /usr/share/ghostscript/PDFA_def.ps \
   input.pdf

Python — pikepdf

import pikepdf

# Open existing PDF and save as PDF/A (requires all fonts already embedded)
with pikepdf.open("input.pdf") as pdf:
    # Add XMP metadata for PDF/A identification
    with pdf.open_metadata() as meta:
        meta["pdfaid:part"] = "2"
        meta["pdfaid:conformance"] = "B"
    pdf.save("output_pdfa.pdf")

Validating PDF/A Compliance

Creating a file as PDF/A is not the same as having a valid PDF/A file — tools can produce non-compliant output while claiming compliance. Always validate:

VeraPDF (open-source reference validator)

# Validate PDF/A conformance
verapdf --flavour 2b document.pdf

# Validate and output detailed report
verapdf --format text --verbosity 6 document.pdf > report.txt

# Batch validate directory
verapdf --flavour 1b *.pdf

Apache PDFBox

# Validate with PDFBox preflight
java -jar pdfbox-app-3.x.jar PDFAValidator document.pdf

Common validation failures:

• Missing font embedding (most common)
• Missing ICC color profile or OutputIntent
• Missing XMP metadata
• Invalid XMP structure
• Use of prohibited features (JavaScript, encryption)
• Incorrect PDF structure (corrupt cross-reference table)

PDF/A Use Cases and Industry Requirements

PDF/A vs. Regular PDF vs. PDF/X vs. PDF/UA

Summary

PDF/A answers a specific question: "Will this document render identically in 50 years?" By mandating font embedding, ICC color profiles, XMP metadata, and prohibiting encryption and external dependencies, PDF/A creates self-contained archival artifacts. For organizations with long-term document retention requirements — government, legal, healthcare, financial, cultural heritage — PDF/A is not optional but a compliance requirement. Always validate PDF/A files with VeraPDF after creation, as many tools produce non-compliant output despite claiming PDF/A export support.

Related conversions

Document conversions that follow this topic naturally:

• PDF to DOCX
• DOCX to PDF
• MD to PDF
• HTML to PDF
• ODT to PDF
• PDF to TXT