PDF/A

Short definition

PDF/A is the archive-grade variant of PDF, standardised as ISO 19005. It is intentionally more restrictive than regular PDF: anything that could jeopardise long-term, identical rendering is disallowed — external fonts, JavaScript, encryption, audio/video content.

PDF/A was designed for archives, public authorities and anyone who needs documents to render unchanged for decades.

The versions

Version	ISO	Year	Base PDF	Added
PDF/A-1	19005-1	2005	PDF 1.4	baseline archive format
PDF/A-2	19005-2	2011	PDF 1.7	layers, JPEG 2000, PDF-only attachments
PDF/A-3	19005-3	2012	PDF 1.7	arbitrary file attachments
PDF/A-4	19005-4	2020	PDF 2.0	simplified conformance levels

PDF/A-3 is the foundation for ZUGFeRD — the hybrid invoice format uses the extended attachment mechanism to embed an XML invoice inside the PDF.

Conformance levels

Each PDF/A version has conformance levels suffixed to the version:

• -b (basic) — visual identity: guaranteed look, not necessarily searchable
• -a (accessible) — adds Tagged PDF, Unicode mapping, logical structure → accessible
• -u (unicode, PDF/A-2/3 only) — between -b and -a: Unicode mapping present, no full structure

Specs then reference e.g. PDF/A-3b (most common for ZUGFeRD) or PDF/A-2a (public administration with accessibility).

What is forbidden in PDF/A?

• Embedded files except in PDF/A-3 (with restrictions)
• Encryption and password protection
• JavaScript
• External references required for display
• Non-embedded fonts
• Transparency (PDF/A-1 only)
• LZW compression

Creating PDF/A with the Dokmatiq API

Any PDF generated by DocGen can be emitted as PDF/A directly:

curl -X POST https://api.dokmatiq.com/v1/pdf/convert \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -H "Content-Type: application/pdf" \
  -H "X-Target-Profile: PDF/A-3b" \
  --data-binary "@input.pdf" \
  -o archive.pdf

For newly generated documents pass outputProfile: "PDF/A-3b" in the request. The API embeds missing fonts, adds the required XMP metadata and validates the result against VeraPDF before returning it.

When is PDF/A mandatory?

• ZUGFeRD invoices: PDF/A-3 required
• Electronic file in German public administration: usually PDF/A-2 or -3
• GoBD-compliant archiving (tax/accounting): PDF/A recommended, not strictly required
• Long-term archiving per DIN ISO 14721 (OAIS): PDF/A is the default

Common pitfalls

1. Fonts not embedded — the top reason VeraPDF validation fails
2. Transparency in PDF/A-1 — modern design tools introduce transparency that must be flattened first
3. Colour profiles — PDF/A requires DeviceGray/DeviceRGB with an ICC profile or CMYK with an output intent
4. Converting an existing PDF is harder than producing PDF/A-compliant output in the first place