2026-05-04 · 9 min read

PDF/A vs PDF: When to Use Each Archival Format

Most people have never made a deliberate choice between PDF and PDF/A. Then someone — a court clerk, an HR system, a tax authority — rejects their submission because it “must be PDF/A.” Suddenly the difference matters. Here’s what PDF/A actually is, why it exists, the four conformance levels, and when you should care.

Why a separate archival standard exists

Regular PDF is enormously flexible. The format supports JavaScript, embedded video, encryption, links to external files, font references that aren’t embedded, transparency tricks that depend on a specific colour management library being available, and dozens of other features. Most of those make a document great today and unreadable in 30 years. The font reference goes stale, the JavaScript engine changes, the external resource disappears, the colour profile is no longer interpreted the same way.

Archives — national libraries, courts, regulators, research institutions — need documents that will still render identically in 2050. PDF/A (defined in ISO 19005, first published 2005) is the constrained subset that makes this possible. It bans the dynamic and external bits, requires self-containment, and forces enough metadata to identify the document long after the original software is gone.

What PDF/A removes from regular PDF

The big restrictions:

• No external content. All fonts, images, and colour profiles must be embedded. A PDF/A is a self-contained package.
• No JavaScript. Forms can exist (in some levels) but interactive scripts can’t.
• No encryption. Archives need to be readable now and later, not locked behind keys that may be lost.
• No audio, no video, no executable attachments.
• No transparency or LZW compression in older levels.
• Required XMP metadata. Title, author, creation date — written in a standard XML metadata block readable by any tool.
• Embedded colour profile (ICC). So colours render the same way without depending on the OS’s current settings.

The result: a PDF/A file is typically larger than the equivalent PDF because everything is embedded, and somewhat less interactive. In return, it’s far more likely to look identical 30 years from now.

The four conformance levels

PDF/A has multiple parts and conformance levels. The ones you’ll actually see:

Each version (except A-4) also has conformance levels:

• Level B (Basic): the file renders consistently. Bare minimum.
• Level U (Unicode): text is present and Unicode-mapped — searchable and copyable. Added in A-2.
• Level A (Accessible): proper structural tagging (headings, lists, alt text) — readable by screen readers and re-flowable.

A typical real-world request: “Submit as PDF/A-2b” — version 2, conformance level B. Or “PDF/A-3a” for an accessible electronic invoice with embedded XML.

When you actually need PDF/A

Concrete situations where PDF/A is required, not optional:

• Court filings (US PACER, German Justizportal, etc.): most courts require PDF/A-1 or PDF/A-2.
• National archives (Library of Congress, UK National Archives, French Archives Nationales): all standardise on PDF/A.
• Tax authorities in many EU countries require PDF/A for audit-relevant document storage (10-year retention).
• Electronic invoices under European e-invoicing standards (Factur-X, ZUGFeRD) use PDF/A-3 with embedded XML.
• Patent offices (USPTO, EPO) require PDF/A for submissions.
• Scientific journals and dissertations for long-term deposit.

For day-to-day work — sending a proposal, sharing a report, posting a white paper — regular PDF is fine and often better, since features like form interactivity and encryption matter more than 50-year archivability.

How to convert regular PDF to PDF/A

Several free options:

• LibreOffice: File → Export As → Export as PDF → check “Archive (PDF/A).” Choose A-1, A-2, or A-3 from the dropdown.
• Microsoft Word: Save As → PDF → Options → check “PDF/A compliant.”
• Ghostscript: the command-line workhorse:

gs -dPDFA=2 -dBATCH -dNOPAUSE \
   -sProcessColorModel=DeviceRGB \
   -sDEVICE=pdfwrite \
   -sOutputFile=output.pdf \
   PDFA_def.ps input.pdf

For verification, the open-source veraPDF tool is the gold standard for PDF/A conformance checking — recommended even by the PDF Association. Run it after conversion to confirm your file actually meets the spec.

Common PDF/A pitfalls

• Non-embedded fonts. The most common conformance failure. Common system fonts (Helvetica, Times) are often referenced rather than embedded — fine in regular PDF, fatal in PDF/A.
• Encryption. A password-protected PDF cannot be PDF/A. Decrypt first.
• Transparency. Allowed in A-2 onwards, banned in A-1. A common reason a converted file passes A-2 validation but fails A-1.
• Missing colour profile. If the document has any colour content, an ICC profile must be embedded.
• External hyperlinks. Allowed (the URL itself is embedded), but the linked content isn’t guaranteed to exist forever — not a conformance failure, but a logical one for archives.

A simple rule

If a system requires PDF/A, give them PDF/A. If it doesn’t, regular PDF is friendlier, smaller, and more interactive. Don’t archive everything as PDF/A by default — the extra embedded fonts and colour profiles can balloon file sizes by 30–50%, and some features you might want (encryption, form scripting) are off limits.

For sensitive documents that also need to be archived, the right pattern is: PDF/A version for the archive, regular encrypted PDF for active distribution. They serve different jobs and one file rarely does both well. For more on encrypted PDFs and password protection, see our guide to PDF security.

Need to do something with the PDF before you archive it — convert, edit, extract? Our browser-based PDF tools run on-device, so even sensitive archive material never leaves your machine.