A normal PDF may still look exactly the same in ten years, or it may not, because a font is missing or a plug-in has disappeared. PDF/A closes exactly this gap: a format that guarantees a document will still look exactly as it does today even decades from now. What it's meant for, how the versions differ, and why it's highly topical in Germany right now.

The problem: PDFs aren't archive-ready by nature

An ordinary PDF is allowed to rely on its environment. It can point to fonts that were installed on the creator's system but aren't embedded. It can use proprietary color spaces, reference external content, or only build correctly via JavaScript when opened.

As long as the right software and all resources are present, this works fine. But for an archive designed to last decades, these very dependencies are the risk: what if the font is missing, the reader no longer knows the feature, the external content is offline?

The solution: PDF/A as a self-sufficient subset

PDF/A (standardized in the ISO 19005 series) is a deliberately restricted variant of PDF. The basic idea: a PDF/A document must contain everything it needs for faithful display, without relying on anything outside the file.

From this follow the central rules:

  • All fonts must be embedded, so no reliance on system fonts.
  • Device-independent colors (ICC profiles) for consistent color reproduction.
  • XMP metadata is mandatory for the essential document properties.
  • Encryption is forbidden, because the document must remain accessible long-term.
  • No JavaScript, no external references, so nothing that can later lead nowhere.

The versions: A-1 to A-4

PDF/A has grown over the years in several parts, each building on a newer PDF base:

VersionYearPDF baseMost important addition
PDF/A-12005PDF 1.4strictest subset, no transparency
PDF/A-22011PDF 1.7transparency, layers, JPEG 2000, digital signatures (PAdES)
PDF/A-32012PDF 1.7allows arbitrary embedded files
PDF/A-42020PDF 2.0modern baseline, variant 4e for 3D/engineering

PDF/A-1 is the most restrictive and for that very reason the most broadly compatible; authorities with legacy systems often mandate PDF/A-1b. PDF/A-2 relaxes sensible restrictions (transparency, layers). The decisive leap with PDF/A-3 is the ability to embed arbitrary files. More on that shortly.

The conformance levels: a, b, u

Within a version there are levels describing how much is guaranteed:

  • Level B (basic) guarantees the reliable reproduction of the appearance. It is the minimum level and the most commonly used.
  • Level A (accessible) builds on B and adds a tagged logical structure (Tagged PDF), Unicode mappings for all text, and the language specification. This enables text extraction, screen readers and accessibility, but is significantly more involved to produce correctly.
  • Level U (Unicode) is available from PDF/A-2: like Level B, but with Unicode mapping for all text, so searchable, without the full effort of Level A.

Technically the file records this in two XMP properties: pdfaid:part (the version 1–4) and pdfaid:conformance (the level A/B/U).

The Germany angle: e-invoicing and audit-proof archiving

Two reasons make PDF/A particularly relevant in Germany.

First, audit-proof archiving. Anyone who has to retain business records under the GoBD needs a format that ensures unchanged, faithful reproduction over the entire retention period, exactly what PDF/A was designed for.

Second, e-invoicing. The hybrid format ZUGFeRD (and its French counterpart Factur-X) embeds a machine-readable XML invoice directly into a PDF/A-3. Humans see the familiar PDF invoice, accounting systems read out the embedded XML automatically, both in a single, archive-ready file. This very embedding capability is the reason PDF/A-3 became the basis here. For anyone building ordering or invoicing systems, this is no longer a fringe topic.

Decision guide

  • Authority / legacy systems → PDF/A-1b
  • Searchable archive → PDF/A-2u
  • Accessibility required → Level A (1a/2a)
  • Hybrid e-invoice (ZUGFeRD/Factur-X) → PDF/A-3
  • Newest base, engineering/3D → PDF/A-4 (or 4e)

What to watch out for when creating one

A PDF doesn't become a PDF/A "by accident". On export, the conformance profile must be actively selected, and the tool must enforce the rules: embed fonts, set the color profile, remove forbidden elements. Whether a file is really conformant is best checked with a validator (e.g. the open-source veraPDF) before it goes into the archive, because "looks like a PDF" and "meets ISO 19005" are two different things.

Convert documents with wandlio

Around PDFs and documents at wandlio:

Document conversions run server-side, and your file is always deleted afterwards.