What Makes PDF/A Different From Ordinary PDF #

PDF/A is the ISO-standardized archival profile of PDF (the ISO 19005 family). It constrains PDF so that a file is fully self-contained and renders identically forever:

  • All fonts are embedded: no dependency on fonts installed on a future system
  • No external references: everything needed for rendering is inside the file
  • No active content: no JavaScript, no embedded executables
  • Device-independent color: defined color spaces instead of ​“whatever the screen does”
  • Standardized metadata: XMP metadata for indexing and provenance

An ordinary PDF may rely on system fonts, link to external resources, or contain scripts. Any of these can silently break rendering years later.

The PDF/A Versions: PDF/A‑1 to PDF/A‑4 #

The ISO 19005 family has four parts; all remain valid for archiving.

  • PDF/A‑1 (ISO 19005 – 1): the strictest profile, based on PDF 1.4. Two conformance levels: PDF/​A‑1b (reliable visual reproduction) and PDF/​A‑1a (additionally tagged structure for accessibility and text extraction). Good for scanned documents; no transparency or JPEG2000.
  • PDF/A‑2 (ISO 19005 – 2): based on PDF 1.7. Adds transparency, JPEG2000 compression, layers, and allows embedding other PDF/A files. The pragmatic default for most archives today.
  • PDF/A‑3 (ISO 19005 – 3): like PDF/A‑2, but allows embedding arbitrary file attachments. This is the basis for hybrid invoice formats used in e‑invoicing (a PDF/A rendering plus embedded structured XML data).
  • PDF/A‑4 (ISO 19005 – 4): based on PDF 2.0, simplifies the conformance levels and adds variants for engineering documents (PDF/​A‑4e) and embedded files (PDF/​A‑4f).

Practical guidance: scanned paper goes well into PDF/​A‑1b or PDF/​A‑2b; born-digital documents into PDF/A‑2; e‑invoices follow the PDF/A‑3 based national profiles; new implementations can target PDF/A‑4.

Conversion and Validation #

Conversion: Most DMS and capture systems convert to PDF/A at ingest. Standalone conversion is possible with office suites (export as PDF/A), Ghostscript, or commercial tools with batch and OCR capabilities. Convert at the point of archiving, not years later: the source application must still be available for a faithful conversion.

Validation: A file with a “.pdf” extension is not automatically valid PDF/A. Use a validator (the open-source veraPDF validator is the reference implementation) to check conformance before archiving. Invalid files discovered at ingest are fixable; invalid files discovered in year nine of retention often are not.

Process: Document the conversion and validation step in your archiving process documentation. Auditors check that reproducibility is ensured by process, not by luck.

Format and Storage Belong Together #

PDF/A solves readability; it does not solve integrity. A PDF/A file on an ordinary file server can still be altered or deleted by anyone with sufficient rights. Audit-proof archiving needs both layers:

  • Format layer: PDF/A ensures the record renders correctly for decades
  • Storage layer: hardware (for example Silent Cubes, with redundant erasure-coded storage designed for very long retention) ensures the record cannot be altered or deleted during the retention period

Together they answer the two questions every auditor asks: can you open it, and can you prove nobody changed it?

Further Resources #

→ Guide (/en/blog/revisionssicherheit-leitfaden/) → The 10 Criteria of (/en/blog/10-kriterien-revisionssicherheit/) → The 6 Most Common Mistakes in (/en/blog/6‑fehler-revisionssichere-archivierung/) → Silent Cubes: Hardware Archive Storage (/en/produkte/silent-cubes/)

Disclaimer

This article was written by our editorial team and edited using AI. It provides a general overview and does not constitute legal advice – we recommend seeking professional advice for your specific situation.