PDFSomething

PDF/A vs PDF: which to use for long-term archiving

2026-09-19 · 6 min read

A PDF that opens perfectly today can quietly rot. PDF/A is the ISO subset built to stop that. Here is what it locks down and when the stricter format actually earns its place.

The quiet failure of an ordinary PDF

PDF was designed to look the same everywhere, and most of the time it does. But the format is generous: it lets a file reference things it expects to find elsewhere rather than carry them inside. A document can point to a font by name and trust the reader's computer to supply it. It can lean on a viewer's default behaviour for colour, transparency, or a scripting feature. None of that matters when you open the file five minutes after making it on the same machine. It matters a great deal when someone opens it in fifteen years, on software that has not been written yet, on a device that no longer ships the fonts you assumed.

This is the archival problem. A file that renders by depending on its environment is only as durable as that environment. Swap the fonts, drop the plugin, change the default colour handling, and the page you so carefully laid out can reflow, substitute glyphs, or shift colour. The document did not change; the world around it did.

What PDF/A changes

PDF/A is not a different file type you have to learn. It is an ISO standard (ISO 19005) that defines a subset of PDF: the same format with the fragile parts forbidden and the durable parts made mandatory. The governing idea is self-containment. A PDF/A file is supposed to carry everything it needs to render faithfully, so that a conforming reader can reproduce it without reaching outside the file.

In practice that means a handful of firm rules:

  • All fonts must be embedded. The glyph outlines travel inside the document, so there is nothing to substitute and nothing to guess. This is the same font-embedding idea explored in why PDF fonts look wrong on another computer, applied as a hard requirement rather than a best practice.
  • No external dependencies. Content that would need to be fetched or resolved from outside the file is not allowed.
  • No encryption. A password-locked file cannot be reliably opened by future software, so PDF/A prohibits encryption outright.
  • Device-independent colour. Colours are described in a way that does not assume a particular monitor or printer, typically by embedding a colour profile, so a red stays the same red decades later.
  • Restricted dynamic features. JavaScript, embedded audio and video, and launch actions are disallowed or tightly limited, because behaviour that runs is behaviour that can break.

Conformance levels, honestly

PDF/A comes in versions (PDF/A-1, -2, -3 and later) that track the underlying PDF version and relax or add capabilities. Within a version you will see letters. The distinction worth remembering is the one between b and a: a level like PDF/A-1b certifies basic visual reproduction (the file will look right), while PDF/A-1a additionally requires the structure needed for accessibility, such as a tagged reading order and mapping of text to actual characters. Roughly: b guarantees the eye sees it correctly, a also guarantees a screen reader and a machine can navigate it. If a submission portal names a specific level, follow it exactly rather than assuming; the levels are not interchangeable, and the finer differences between versions are best checked against the requirement you were given.

TraitOrdinary PDFPDF/A
FontsMay be embedded, subset, or only referenced by nameMust be fully embedded
Encryption allowed?Yes (passwords, permissions)No, prohibited
External dependenciesPermitted (system fonts, linked content)Not permitted, everything self-contained
Dynamic contentJavaScript, audio, video allowedRestricted or forbidden
Best forEveryday sharing, editing round-trips, interactive formsRecords that must render identically for years

When you actually need PDF/A

The stricter format is not a general upgrade, and treating it as one wastes effort. You need PDF/A when a document's job is to survive and be trusted over time:

  • Legal and court filings. Many electronic filing systems mandate PDF/A precisely so the record cannot depend on fonts or software that a future reader may lack.
  • Government and regulatory submissions. Agencies that keep documents as an official record often require a conformance level by name.
  • Records retention. Contracts, medical or financial records, academic theses, and anything with a multi-year or permanent retention schedule are exactly what the standard was written for.

For everything else, an ordinary PDF is the right choice. A file you email to a colleague this afternoon, a form you will fill in and send back, a draft that still needs edits, an invoice that will be paid and forgotten in ninety days: none of these benefit from being frozen into an archival subset, and the loss of encryption and interactivity can be an active nuisance.

Where our tools fit around the edges

Even though we don't convert to PDF/A, a few of the format's themes overlap with tools here. Font embedding is the biggest one: if you are starting from a Word document, our Word-to-PDF converter renders on a server to a fixed layout and embeds the fonts it uses, which is a more archival-friendly starting point than exporting a file that merely names its fonts. (That tool uploads your file for conversion and deletes it immediately afterwards, see the Word-to-PDF guide for the details.)

Because PDF/A also cares about what a file discloses, it is worth knowing what yours carries: our metadata tool shows the author, producing software and timestamps stored inside a document, all in your browser. And if a file has simply grown bloated over years of edits, Optimize PDF rebuilds its internal structure losslessly, without altering a single page, so an archive copy weighs no more than its content requires. Neither of these makes a file conformant, but both are sensible steps before you commit a document to long-term keeping.