PDF/A Explained: What Long-Term Archiving Actually Requires

PDF/A exists to answer one question: will this file still render identically in forty years, on software that does not exist yet? Ordinary PDF cannot promise that, because it can reference resources it does not contain.

The core rule: self-containment

A PDF/A file must carry everything it needs inside itself. Every font fully embedded. Every colour space explicitly defined rather than device-dependent. No external references, no JavaScript, no audio or video, no encryption, no transparency in the older levels. If the file needs something from outside itself to render, it is not PDF/A.

Conformance levels, briefly

• Level B (basic): guarantees the visual appearance is reproducible. This is the common requirement and the easy one to meet.
• Level A (accessible): adds structural tagging, logical reading order and Unicode mapping — so the document is machine-readable and accessible to screen readers, not just visually faithful.
• Level U: level B plus Unicode text mapping, without full structural tagging. A useful middle ground when text extraction matters but full tagging is impractical.

Versions PDF/A-1 through PDF/A-4 differ mainly in what they permit: A-1 is the strictest and forbids transparency and layers; A-2 and A-3 relax that and allow embedded attachments; A-3 notably allows arbitrary embedded files, which is how e-invoicing standards ship XML inside a human-readable PDF.

What conversion strips

1. Encryption and permissions — archival formats must be openable without a key.
2. Embedded multimedia and JavaScript.
3. Non-embedded fonts, which get substituted or embedded from a system equivalent. Watch for reflowed line breaks here.
4. External hyperlinks may survive as text but stop being guaranteed to resolve.
5. Transparency effects, in PDF/A-1, which get flattened into composited images.

When you genuinely need it

Court filings, regulatory submissions, tax records, institutional repositories, and any document with a legally mandated retention period. If nobody has asked for PDF/A, you probably do not need it — the constraints cost you features for a benefit measured in decades.

Validate, do not assume

A file being produced by a PDF/A converter is not proof it conforms. Run it through a validator and check for the conformance claim in the XMP metadata. Submissions get rejected on this constantly, usually for one non-embedded font in a footer nobody looked at.

The ISO standard behind the marketing term

PDF/A is formally defined by ISO 19005, published in parts that map to the version numbers in common use: ISO 19005-1 defines PDF/A-1, ISO 19005-2 defines PDF/A-2, ISO 19005-3 defines PDF/A-3, and ISO 19005-4 defines PDF/A-4, which moved the underlying base from the older PDF 1.4-era specification to ISO 32000-2 and dropped the A/B/U letter suffixes in favour of simpler 'PDF/A-4' and 'PDF/A-4f' designations. When a regulator's guidance says 'PDF/A' without a number, assume they mean PDF/A-1b unless told otherwise — it remains the most widely mandated baseline specifically because it is the strictest and therefore the safest common denominator across systems built at different times.

PDF/A-1b versus PDF/A-2b versus PDF/A-3b in practice

PDF/A-1b is the conservative choice: no transparency, no JPEG2000 compression, no layers, and no ability to embed arbitrary files other than other PDF/A files. PDF/A-2b, published later, added support for JPEG2000, transparency, layers (OCGs), and the ability to embed other PDF/A files — useful for combining scanned attachments without flattening them into images first. PDF/A-3b keeps everything from A-2b and adds the ability to embed any file type at all, not just PDF/A files, which is the mechanism behind formats like ZUGFeRD and Factur-X that embed a machine-readable XML invoice inside a human-readable PDF wrapper. The practical rule: use A-1b unless a specific feature in A-2 or A-3 is required by the receiving system, because every added feature is one more thing a strict validator can find fault with.

A worked example: why a font substitution breaks a signature block

Consider a contract PDF built with a licensed corporate font that was referenced but not embedded in the original file — common when a document is exported quickly from a word processor with default settings. Converting it to PDF/A-1b forces full font embedding, and since the original font file is not embedded and possibly not licensed for embedding, the converter substitutes a metrically similar system font. The visible text usually still fits on the same lines, but tight layouts — a signature block with a name, date and title stacked in a fixed-height box — can reflow by a line or two, and a name field engineered to align exactly with a printed line above it can drift by a few points. This is why archival conversion of anything with a signature block, a form, or dense tabular layout needs a visual diff against the original before filing, not just a conformance pass.

The XMP metadata block, and what to actually look for

Conformance is asserted, not just achieved structurally: a compliant file carries an XMP metadata packet with a pdfaid:part field (1, 2, 3 or 4) and a pdfaid:conformance field (A, B or U). A file can be structurally close to conformant and still fail validation if this metadata block is missing, malformed, or claims a level the file does not actually meet — which happens when a file is edited after conversion by a tool that does not preserve or update the XMP block. When troubleshooting a rejected submission, open the file's XMP metadata first: a missing or contradictory conformance claim is a faster diagnosis than re-running a full validator pass.

Common rejection reasons, ranked by how often they actually occur

1. A single non-embedded font, frequently in a header, footer, or a form field added after the main conversion pass.
2. An image using an unsupported colour space, such as an uncalibrated ICC-less CMYK image inserted post-conversion.
3. Encryption reapplied after conversion, usually by a downloading or printing tool that defaults to password protection.
4. A missing or incorrect XMP conformance declaration after a later edit was made without a PDF/A-aware tool.
5. Optional content (layers) present in a file declared as PDF/A-1, which forbids them entirely.

Troubleshooting checklist before submission

1. Run a dedicated PDF/A validator, not just 'save as PDF/A' from an editor — the export step and the conformance guarantee are not the same thing.
2. Check the XMP metadata for a pdfaid:part and pdfaid:conformance field that matches what you intend to claim.
3. Search the font list in the document properties for any font not marked embedded — every one is a rejection risk.
4. If the document has a signature block, form fields, or a tightly aligned layout, visually diff it against the pre-conversion original at 100 percent zoom.
5. Confirm no password, permissions restriction, or encryption has been applied after the conversion step.
6. If embedding attachments (PDF/A-3), confirm the receiving system actually expects that profile — some validators will reject A-3 files where only A-1b or A-2b was specified.

"A converter's export dialog can claim PDF/A compliance. Only a validator reading the file back can confirm it."

PDF/A versus PDF/UA: two standards people confuse

PDF/A (ISO 19005) is about long-term visual and structural preservation. PDF/UA (ISO 14289, Universal Accessibility) is a separate standard about accessibility for assistive technology, and the two overlap but are not the same thing: PDF/A-1a and PDF/A-2a require tagging for accessibility as part of achieving Level A conformance, but meeting PDF/A-1a does not automatically mean a document passes a full PDF/UA accessibility audit, which checks additional criteria such as reading order fidelity, alternative text quality, and correct table header association. If a regulator's requirement mentions both archival retention and accessibility for public-facing documents, check whether they mean PDF/A alone or PDF/A plus PDF/UA — treating them as interchangeable is a common cause of a document passing one audit and failing the other.

A realistic timeline for retrofitting an existing archive

Organisations that discover a mandate applies retroactively to years of existing PDFs face a bulk-conversion problem, and the two variables that actually determine how long it takes are font licensing and scanned-image volume, not raw file count. Native PDFs with standard, embeddable fonts convert in bulk with minimal manual review. Files with unembedded proprietary fonts need either a licensing check or a substitution decision made once and applied consistently. Scanned pages need OCR before Level A or Level U conformance is even meaningful, since a page of pure image data has no extractable text layer to make Unicode-mappable. Budget review time in proportion to how much of the archive falls into those two harder categories, not the total page count.