PDF/A: The Archival PDF Standard — Complete Guide
PDF/A is the ISO-standardized version of PDF designed specifically for long-term digital preservation. Governments, courts, libraries, hospitals, and financial institutions around the world mandate PDF/A for records that must remain readable decades or centuries into the future. Understanding PDF/A — its conformance levels, technical requirements, and validation — is essential for anyone managing official documents or building document archival systems.
Why PDF/A Exists
A regular PDF file can reference external resources (URLs, fonts, color profiles) that may not exist in the future. It can contain JavaScript that could behave unpredictably. It can encrypt content in ways that make it unreadable without the right software and key. And it can use proprietary features that only specific reader versions understand.
PDF/A eliminates all of these risks by requiring that a PDF/A file be completely self-contained and technology-neutral — everything needed to render it identically on any conforming reader, now or in 500 years, must be embedded in the file itself.
PDF/A Standards: A Family of ISO Specifications
| Standard | Year | Based On | Profiles | Key Additions |
|---|---|---|---|---|
| PDF/A-1 | 2005 | PDF 1.4 | 1a, 1b | Core requirements established |
| PDF/A-2 | 2011 | PDF 1.7 | 2a, 2b, 2u | JPEG2000, layers, digital signatures, PDF/A attachments |
| PDF/A-3 | 2012 | PDF 1.7 | 3a, 3b, 3u | Any file as embedded attachment (not just PDF/A) |
| PDF/A-4 | 2020 | PDF 2.0 | 4, 4e, 4f | Updated to PDF 2.0, no more A/B/U designation |
Conformance Levels Explained
Within each standard, conformance levels define how strictly accessibility and unicode requirements are enforced:
| Level | Name | Requirements |
|---|---|---|
| a (Accessible) | Most strict | Tagged PDF with logical structure, alt-text for images, actual text for all content, language specification. Screen-reader accessible. |
| b (Basic) | Standard | All visual requirements: embedded fonts, device-independent colors, no encryption. No structural/accessibility requirements. |
| u (Unicode) | Intermediate (PDF/A-2/3 only) | Level b requirements + all text must have Unicode mapping. Allows text extraction and search. |
PDF/A-1b is the most commonly required level for general records archival. PDF/A-1a is required when accessibility (screen reader support) is mandated. PDF/A-3b is used for e-invoicing (ZUGFeRD in Germany, Factur-X in France) because it allows arbitrary file attachments (e.g., XML invoice data embedded in the PDF).
Technical Requirements for PDF/A Compliance
A compliant PDF/A file must satisfy all of the following:
Fonts
- All fonts must be embedded in the PDF — no system font references
- Font encoding must allow extraction of character-to-glyph mapping
- Glyphs must match the Unicode codepoints they represent (level u/a)
Color
- All colors must be device-independent: use ICC-profiled color spaces
- No DeviceRGB, DeviceCMYK, or DeviceGray without an embedded ICC profile (these can lead to device-dependent rendering)
- An OutputIntent must be present in the PDF, specifying the intended rendering device
Metadata
- XMP metadata is mandatory (not just optional as in regular PDF)
- Required XMP namespaces: dc: (Dublin Core), pdf: (PDF properties), xmp:
- The PDF/A conformance level must be declared in the
pdfaid:namespace:<pdfaid:part>1</pdfaid:part> <pdfaid:conformance>B</pdfaid:conformance>
Prohibited Features
- No encryption (document must be readable without password)
- No JavaScript actions
- No external content references (URLs, linked files that might disappear)
- No multimedia content (movies, audio) — PDF/A-1; PDF/A-2/3 allow some
- No transparency operators — PDF/A-1 only; PDF/A-2/3 allow transparency
- No LZWDecode filter (patent concern in 2005; PDF/A-1 prohibition)
- No 3D artwork (PDF/A-1/2/3)
Creating PDF/A with LibreOffice
LibreOffice is the most accessible free tool for creating PDF/A:
- File → Export as PDF
- In "General" tab: check "Archive (PDF/A, ISO 19005)"
- Select conformance: PDF/A-1b, PDF/A-1a, PDF/A-2b, etc.
- Ensure all fonts are embedded (LibreOffice embeds by default)
Command-line conversion with LibreOffice headless:
# Convert DOCX to PDF/A-1b
libreoffice --headless --convert-to pdf \
--infilter="writer_pdf_Export" \
--outdir /output/ input.docx
# Note: headless LibreOffice uses the PDF export settings from its config
# For guaranteed PDF/A output, use a macro or a dedicated tool
Creating PDF/A with Ghostscript
# Convert any PDF to PDF/A-1b
gs -dNOPAUSE -dBATCH -dSAFER \
-sDEVICE=pdfwrite \
-dPDFA=1 \
-dPDFACompatibilityPolicy=1 \
-sColorConversionStrategy=UseDeviceIndependentColor \
-sOutputFile=output_pdfa.pdf \
PDFA_def.ps \
input.pdf
# The PDFA_def.ps file is a Ghostscript preamble that sets OutputIntent
# A minimal PDFA_def.ps:
cat > PDFA_def.ps << 'EOF'
%!
% This file is required to set up Ghostscript for PDF/A output.
[ /Title (PDF/A Document)
/DOCINFO pdfmark
[ /Name (ISO_19005-1)
/Creator (Ghostscript)
/GTS_PDFXVersion (PDF/A-1B)
/Info currentdict
/DOCINFO pdfmark
EOF
# Simpler one-liner for basic PDF/A-2b conversion
gs -dNOPAUSE -dBATCH \
-sDEVICE=pdfwrite \
-dPDFA=2 \
-dCompatibilityLevel=1.7 \
-sOutputFile=output_pdfa2.pdf \
input.pdf
Validating PDF/A with VeraPDF
VeraPDF is the industry-standard open-source PDF/A validator:
# Install VeraPDF
# Download from https://verapdf.org/ or:
# On Linux: sudo apt install verapdf
# Validate a file for PDF/A-1b compliance
verapdf --flavour 1b input.pdf
# Output formats
verapdf --flavour 1b --format text input.pdf # Human-readable
verapdf --flavour 1b --format json input.pdf # Machine-readable
verapdf --flavour 1b --format xml input.pdf # XML report
# Auto-detect conformance level from file's own declaration
verapdf input.pdf
# Batch validate a directory
verapdf --flavour 2b /path/to/pdfs/*.pdf
VeraPDF reports:
- Validation passed / Validation failed
- For failures: specific rule IDs (e.g.,
1-7-3: missing font file for embedded font) - Section references to the ISO 19005 standard
Python: Creating and Validating PDF/A
from reportlab.pdfgen import canvas
from reportlab.lib.colors import HexColor
from reportlab.pdfbase import pdfmetrics
from reportlab.pdfbase.ttfonts import TTFont
import subprocess
def create_pdfa(output_path):
"""Create a minimal PDF/A-compliant document with ReportLab."""
c = canvas.Canvas(output_path)
# Set PDF/A metadata
c.setAuthor("KaijuConverter")
c.setTitle("PDF/A Example Document")
c.setSubject("Archival document")
# Embed a font (required for PDF/A)
# ReportLab's built-in fonts are Type 1 and can be embedded
# For TTF: pdfmetrics.registerFont(TTFont('CustomFont', 'font.ttf'))
c.setFont("Helvetica", 14)
c.drawString(100, 750, "This document was created for PDF/A archival.")
c.drawString(100, 720, "All fonts are embedded. No external references.")
# Use sRGB color (device-independent)
c.setFillColor(HexColor('#1a56db'))
c.drawString(100, 690, "Color using sRGB (device-independent)")
c.save()
print(f"Created: {output_path}")
def validate_pdfa(pdf_path, flavour='1b'):
"""Run VeraPDF to validate PDF/A compliance."""
result = subprocess.run(
['verapdf', '--flavour', flavour, '--format', 'text', pdf_path],
capture_output=True, text=True
)
passed = 'PASS' in result.stdout or 'compliant' in result.stdout.lower()
return {
'passed': passed,
'output': result.stdout,
'errors': result.stderr
}
# Apache PDFBox via JPype for more complete PDF/A creation
# pip install jpype1
# Download pdfbox-app-X.Y.Z.jar from pdfbox.apache.org
try:
import jpype
import jpype.imports
jpype.startJVM(classpath=['pdfbox-app-3.0.0.jar'])
from org.apache.pdfbox.pdmodel import PDDocument
from org.apache.pdfbox.pdmodel.common import PDMetadata
doc = PDDocument()
# ... build document with PDFBox API
doc.save('output_pdfa.pdf')
doc.close()
except Exception:
print("JPype/PDFBox not available; use Ghostscript instead")
PDF/A for E-Invoicing: ZUGFeRD and Factur-X
PDF/A-3 enables a powerful use case: embedding structured XML invoice data directly inside a PDF invoice. This is the basis for:
- ZUGFeRD (Germany): XML invoice data embedded in PDF/A-3b
- Factur-X (France/Germany joint standard): Same approach, different XML profiles
- EN16931 (European e-invoice standard): XML embedded in PDF/A-3
The embedded XML file (named factur-x.xml or ZUGFeRD-invoice.xml) contains machine-readable invoice data while the PDF provides human-readable presentation. Tax authorities and ERP systems read the XML; humans read the PDF.
Common PDF/A Validation Errors
| Error | Standard Reference | Solution |
|---|---|---|
| Font not embedded | 6.3.3 | Embed all fonts before creating PDF |
| Missing OutputIntent | 6.2.2 | Add ICC-profiled OutputIntent |
| DeviceRGB without ICC | 6.2.4 | Convert to sRGB with embedded ICC |
| Transparent object | 6.4 (PDF/A-1 only) | Flatten transparency before conversion |
| JavaScript action | 6.6.1 | Remove all JavaScript |
| External URI reference | 6.7 | Remove or substitute external links |
| Missing XMP metadata | 6.7.2 | Add required XMP namespaces |
| Encryption present | 6.3.1 | Remove password protection |
Summary
PDF/A is the definitive format for documents that must survive the test of time. Its three generations (PDF/A-1, -2, -3) progressively relax constraints while adding features, but all share the core principle: self-containment. For standard records archival, PDF/A-1b or PDF/A-2b are appropriate. For accessibility-mandated documents, use PDF/A-1a. For e-invoicing with embedded XML, use PDF/A-3b. Always validate with VeraPDF before submitting to any authority or archival system.
Related conversions
Document conversions that follow this topic naturally: