PDF/A and PDF Standards Explained: Archiving Documents Long Term

What PDF/A Actually Is

PDF/A is ISO 19005, a standard published in 2005 and maintained by the same ISO subcommittee that maintains the underlying PDF specification (ISO 32000). The "A" stands for "archive."

The premise is older than most engineers realize. By the early 2000s, regulators, courts, libraries, and corporate records managers had a problem: they were inheriting digital archives from previous decades whose contents were technically intact but practically unreadable. Documents referenced fonts that were no longer licensed. They embedded executable Flash. They declared color in proprietary profiles whose readers had been discontinued. They linked to URLs that had returned 404 since the second Bush administration.

The solution was not to keep extending PDF. It was to define a strict subset that was guaranteed to render the same way in 2055 as it does in 2025, on a piece of software nobody has written yet.

Three things to keep in mind before going deeper:

• PDF/A is a profile of PDF, not a separate format. A PDF/A file is a perfectly valid PDF. Any compliant viewer can open it. The reverse is not true.
• The standard is about self-containedness. Every font, every color profile, every piece of metadata required to render the document must live inside the file. Anything that depends on the outside world is forbidden.
• PDF/A is enforced by tooling, not by the format itself. A file claiming to be PDF/A is checked by a validator. Lying in the metadata does not make a file conformant.

If you take one sentence away: PDF/A is what PDF would have been if it had been designed in a museum.

The Subfamilies (and Why They Exist)

The PDF/A standard is not one thing. It evolves. Each version of ISO 19005 is built on the corresponding PDF version and adds capabilities the earlier versions could not handle.

Each of those (except PDF/A-4) splits into conformance levels:

• Level B (Basic). Visual reproducibility. The file will look the same forever.
• Level A (Accessible). Visual reproducibility plus structural and semantic information: tagged content, Unicode text mapping, logical reading order. A screen reader can use it.
• Level U (Unicode). A middle level introduced in PDF/A-2 that requires Unicode text but not full structure tagging.

So when somebody says "PDF/A-2b," they mean PDF/A-2, Basic conformance. "PDF/A-1a" is the strictest sensible target. PDF/A-3a is the most permissive widely-supported flavor.

The decision matrix in practice:

• Court filings, contracts, signed agreements: PDF/A-1b is still the most common requirement. Conservative. Maximum compatibility with old viewers.
• Anything with transparency, modern PDF features, or that needs JPEG 2000: PDF/A-2b.
• Hybrid archives where the original source file (XML, CSV, spreadsheet) needs to be preserved alongside the rendered PDF: PDF/A-3 (e.g. ZUGFeRD invoices in Germany embed a structured XML invoice inside a PDF/A-3 visual representation).
• Net-new archival projects in 2026 and later: PDF/A-4. It is the cleanest spec, drops the legacy compliance levels, and is built on PDF 2.0.

If you have no specific reason to pick otherwise, PDF/A-2b is the sensible default for most workflows.

The Rules That Actually Matter

I have read the spec. So that you do not have to, here is what it actually demands.

Fonts must be embedded, fully, with no exceptions

Every font used in the document must be embedded in the file as a subset. "Subset" means only the glyphs actually used, but every glyph that is used must travel inside the PDF. Linked or system fonts are forbidden. This is the rule I see violated most often.

If your export pipeline relies on Arial being installed everywhere (it is not, on Linux systems and many corporate locked-down workstations), the PDF/A version of that document needs Arial embedded. The reason is brutal but obvious: the font you used in 2026 may not exist on the machine that opens the file in 2056. The file has to carry its own typography.

No JavaScript

PDF supports JavaScript. PDF/A does not. JavaScript is executable code, executable code can fail in ways that depend on the runtime, and a runtime in 2056 is not something you can predict. The same logic excludes embedded multimedia (audio, video) and 3D content in PDF/A-1.

No external dependencies

No links to URLs that the document needs to function. No references to external XObjects, fonts, color profiles, or content streams. The document must render correctly in a hermetic environment.

Encryption is forbidden

A PDF/A file cannot be encrypted or password-protected. The reasoning is the same. The cipher you used in 2026 may not have a working implementation in 2056, and "the document is sealed but unreadable" is not preservation.

If you need both archival and confidentiality, the standard practice is to encrypt the transport (encrypted disk, encrypted archive at rest) while keeping the file itself unencrypted PDF/A.

Color must be declared

Every color value has to be tied to a known color space. Most often this means embedding an ICC profile (typically sRGB for screen-oriented documents, a CMYK profile for print). The spec calls this an "OutputIntent." Without a declared intent, a CMYK red on a 2026 inkjet may print as a different CMYK red on a 2056 laser printer.

No transparency in PDF/A-1

This is the rule that catches most modern designers. PDF/A-1 was based on PDF 1.4, which technically supported transparency, but the PDF/A-1 profile excluded it because the rendering rules were considered ambiguous. If you have a transparent logo overlay, a soft-shadow header, or a translucent watermark, PDF/A-1 will reject the file.

This is exactly why PDF/A-2 exists. If you need any of these features, target PDF/A-2 or later.

Metadata must be XMP

PDF supports two metadata formats: an old document info dictionary, and XMP (Extensible Metadata Platform) embedded as XML. PDF/A requires XMP. Validators check that the document's claim of "I am PDF/A-2b" is recorded correctly inside the XMP metadata stream, not just in some side comment.

The Sibling Standards

PDF/A is one of several restrictive PDF profiles. They are easy to confuse and worth keeping straight.

PDF/X for print

ISO 15930. PDF for print production. Where PDF/A is about long-term readability, PDF/X is about predictable color reproduction at a print shop. Different concerns, different rules. PDF/X mandates CMYK or spot colors, embedded ICC output intents tied to specific paper stocks, and no live transparency in some sub-profiles. PDF/X-1a, PDF/X-3, PDF/X-4 are the ones you will see on a print shop's submission guidelines.

A document can be both PDF/A and PDF/X-compliant if it satisfies both rule sets. They were designed to be compatible.

PDF/UA for accessibility

ISO 14289. PDF for universal accessibility. This is the standard your document needs to satisfy if it must be readable by users on screen readers, comply with WCAG, or pass a Section 508 (US federal) or EN 301 549 (EU) audit.

PDF/UA requires tagged content (a logical structure tree), correct reading order, alt text on images, accessible form fields, and Unicode-mapped text. It overlaps with PDF/A's Level A conformance but goes further on accessibility specifics. Government documents in the EU and US increasingly require both PDF/A and PDF/UA.

PDF/E and PDF/VT

PDF/E (ISO 24517) is for engineering and CAD workflows: 3D content, animations, geometric metadata. Almost nobody outside engineering CAD touches it.

PDF/VT (ISO 16612) is for variable-data print runs (think: 100,000 personalized utility bills). High-volume print production. Specialized.

For most workflows the relevant ones are PDF/A and PDF/UA, sometimes PDF/X. The rest are domain-specific.

How to Actually Verify Conformance

The PDF/A claim in a file's XMP metadata is just a string. It can lie. Real verification means running a validator.

veraPDF (open source, the canonical tool)

veraPDF is the reference validator funded by the PDF Association. It is the tool that government archives, national libraries, and digital preservation programs actually use. Free, well-maintained, available as a CLI and a desktop app.

Typical CLI use:

verapdf --format text --flavour 2b contract.pdf

The output tells you not just "valid / invalid" but exactly which rule was violated and where in the file. If you have ever seen output like Rule 6.3.4 violated: subset font not embedded for resource F1, that came from veraPDF.

Adobe Acrobat Pro (Preflight)

Adobe ships a Preflight engine that can validate against PDF/A, PDF/X, and PDF/UA. Convenient if you already have Acrobat Pro. Less granular than veraPDF on the failure detail.

Programmatic validation

If you are building a pipeline that needs to gate documents on PDF/A conformance (a court filing portal, a records management ingestion service), shell out to veraPDF or use its REST API. Do not rely on the metadata claim alone.

Converting a Normal PDF to PDF/A

The conversion from "PDF" to "PDF/A" is rarely a one-line operation. It is a remediation. The most common failure modes I see, in order:

1. Fonts not embedded. The conversion tool flags every glyph that uses a non-embedded font. Fix: re-export from the original source with all fonts embedded.
2. No declared output intent. Add an sRGB ICC profile during export.
3. Transparency in a PDF/A-1 target. Either flatten the transparency at export time or move the target to PDF/A-2 or higher.
4. JavaScript or form actions. Strip them.
5. Encrypted source PDF. Decrypt before converting.

The tools that actually do the conversion well:

• LibreOffice export. Free, open source, has a "PDF/A-1a" and "PDF/A-2b" checkbox in the export dialog. Surprisingly good for simple documents.
• Microsoft Word (modern). Save As PDF, options dialog, "ISO 19005-1 compliant" checkbox. Targets PDF/A-1a only. Sufficient for most contracts.
• Ghostscript. The command-line workhorse for batch pipelines:

gs -dPDFA=2 -dBATCH -dNOPAUSE \
   -sColorConversionStrategy=UseDeviceIndependentColor \
   -sDEVICE=pdfwrite \
   -sPDFACompatibilityPolicy=1 \
   -sOutputFile=output.pdf input.pdf

This produces a PDF/A-2 output. Add a PDFA_def.ps definition file to embed a specific output intent ICC profile.

• Adobe Acrobat Pro. "Save As Other → Archivable PDF (PDF/A)." Slowest on batch volume but the most forgiving on weird input files.

For converting raw images into a PDF/A-friendly document, the StackConvert image-to-PDF tool gives you a clean baseline PDF that your PDF/A conversion tool of choice can then tag. Compression decisions inside the resulting PDF are governed by the same trade-offs covered in Lossy vs Lossless Compression.

Real Use Cases (Why Anyone Cares)

PDF/A is not academic. It is the format on the receiving end of a lot of regulated workflows.

• Court filings. Most U.S. federal court e-filing systems (PACER, CM/ECF) require PDF/A-1 or accept it preferentially. Many state courts the same.
• EU eIDAS-regulated digital documents. Long-term electronic signatures (LTV signatures) are typically embedded in PDF/A-2 or PDF/A-3 documents.
• Sarbanes-Oxley records retention. SOX-regulated companies retain financial records for seven years. PDF/A is the de facto format because it survives the retention window.
• National libraries and digital archives. The Library of Congress, the British Library, and most national archives ingest PDF/A specifically.
• ZUGFeRD and Factur-X invoices (Germany, France). Embed a structured XML invoice as an attachment inside a PDF/A-3 visual representation. The PDF is what humans read; the XML is what the tax authority machine-reads.
• Pharmaceutical and medical device submissions. FDA and EMA submissions often mandate PDF/A.

If you ship software that touches any of these workflows, "we generate PDF" is not the same answer as "we generate compliant PDF/A." The first one will fail validation. The second one will not.

A Decision Matrix That Holds Up

Closing Thoughts

PDF/A is one of those formats that sits in the boring middle of the stack until it suddenly does not. Your tool ships a PDF. Somebody downstream rejects it. You spend a week reading the ISO standard and embedding fonts. Eventually you make the validator green and you forget about it again.

The mental model that fixes this for good: PDF/A is not a kind of PDF. It is a contract between you and a future reader you will never meet. The contract is "this file will look the same to that reader as it does to you, with no outside dependencies, no interactive code, no licensed assets that may not exist anymore." Every rule in the spec follows from that single commitment.

Once you internalize that, the rules stop feeling arbitrary. Fonts embedded, because the future reader does not have your fonts. No JavaScript, because the future reader has no runtime. Color profiles declared, because the future reader has a different printer. The format is the way it is for a reason that takes thirty years to fully appreciate.

If you handle PDFs at scale, the StackConvert PDF tools (compress, merge, split, reorder, Word/PDF round-trip) cover the day-to-day workflow. The PDF/A pass on top of those is what turns "we made a document" into "we made a document that will still be readable when nobody alive worked on the project that produced it."

What is the strangest PDF/A rejection you have ever had to debug?