--- title: "PDF/A as an Archiving Format: Why It Is the Standard for Long-Term Archiving" date: 2026-04-23T11:40:00+02:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/pdf-a-als-archivformat-warum-es-der-standard-für-langzeitarchivierung-ist" section: "Entries: Articles" --- ### What Makes PDF/A Different From Ordinary PDF [\#](#what-makes-pdf-a-different-from-ordinary-pdf "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-pdf-a-versions-pdf-a-1-to-pdf-a-4 "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-and-validation "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 [\#](#format-and-storage-belong-together "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 WORM (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 [\#](#further-resources "Further Resources") → Audit-Proof Archiving Guide (/en/blog/revisionssicherheit-leitfaden/) → The 10 Criteria of Audit-Proof Archiving (/en/blog/10-kriterien-revisionssicherheit/) → The 6 Most Common Mistakes in Audit-Proof Archiving (/en/blog/6‑fehler-revisionssichere-archivierung/) → Silent Cubes: Hardware WORM Archive Storage (/en/produkte/silent-cubes/) ### Audit-Proof Archiving Audit-proof archiving describes the legally required property of an archiving system that preserves documents completely, immutably, traceably and accessibly at all times — and that this can be demonstrated without gaps to tax authorities, auditors and data protection supervisory bodies. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/audit-proof-archiving) ### Audit-Proof Archiving Audit-proof archiving describes the legally required property of an archiving system that preserves documents completely, immutably, traceably and accessibly at all times — and that this can be demonstrated without gaps to tax authorities, auditors and data protection supervisory bodies. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/audit-proof-archiving) ### Audit-Proof Archiving Audit-proof archiving describes the legally required property of an archiving system that preserves documents completely, immutably, traceably and accessibly at all times — and that this can be demonstrated without gaps to tax authorities, auditors and data protection supervisory bodies. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/audit-proof-archiving) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm)