What Is PDF/A, and Does Your Document Actually Need It?
A submission portal rejects your file: it must be PDF/A. Or an archivist asks for PDF/A. Or you read the term in a records policy and cannot tell whether it applies to you.
PDF/A is not a different file format, and it is not a stricter kind of compression. It is an ordinary PDF that has agreed to give some things up.
The idea, in one sentence
A PDF/A file must contain everything needed to render itself, and must not rely on anything outside itself.
That is the whole principle. Everything the standard forbids follows from it.
An ordinary PDF is allowed to make assumptions about the machine opening it: that a font is installed, that a piece of software can play the embedded video, that a linked resource is still reachable. Those assumptions are usually safe today. They are not safe in fifteen years, when the font is gone, the plug-in no longer exists, and the link is dead.
PDF/A removes the assumptions. The file carries its fonts. It carries its colour definitions. It contains nothing that needs external software to display. Open it in 2045 with whatever reads PDFs then, and it renders as it does now.
What it forbids
The restrictions are specific and it is worth seeing them, because they explain why not every document should be one.
- Fonts must be embedded. No exceptions, including the base fonts most software leaves out by convention. This is the single most important rule and it prevents the commonest rendering failure — why a PDF looks different on another computer explains what happens when fonts are missing.
- No encryption. An archived document cannot be locked behind a password that will be lost. This surprises people, and it means PDF/A and password protection are mutually exclusive.
- No audio, video, or executable content. Nothing that needs a plug-in.
- No external references. Everything is inside the file.
- Colour must be unambiguously defined, so a colour means the same thing to any renderer.
- Metadata must follow a defined structure, so archives can index the document reliably.
Read that list again and notice what it costs: no encryption, no interactivity, larger files. Those are real trade-offs, not technicalities.
The versions, briefly
You will see PDF/A-1, PDF/A-2, PDF/A-3, and PDF/A-4, and a submission requirement usually names one.
PDF/A-1 is the original and the strictest, standardised as ISO 19005-1. It is based on an older PDF version and forbids the most.
PDF/A-2 relaxed some restrictions and allowed useful things the first version excluded, including better compression and transparency.
PDF/A-3 added one significant capability: it permits arbitrary files to be embedded inside the document — an invoice can carry its own machine-readable data, for example.
PDF/A-4 is aligned with the current PDF specification.
Each version also comes in conformance levels — commonly b (basic: it will look right) and a (accessible: it will look right and carry structure for assistive technology). A requirement written as “PDF/A-1b” means version 1, basic level.
If a portal specifies a version, use exactly that one. They are not interchangeable, and a validator will reject the wrong one. The PDF Association publishes an accessible introduction covering the differences in detail.
Do you need it?
For most documents, no — and this is where a lot of unnecessary effort gets spent.
You need PDF/A when:
- A submission system, court, tender portal, or registry explicitly requires it. This is by far the most common reason, and the requirement is not negotiable.
- You are depositing something into a formal archive, a library, or a records system with a retention policy measured in decades.
- A regulation covering your sector names it.
- You are digitising records that must remain readable long after the software that made them is gone — the case set out in how to scan and file paper records.
You do not need it for:
- Anything you are emailing to a colleague this week.
- Invoices, quotes, and correspondence with a working life measured in months.
- Any document that needs a password, since PDF/A forbids encryption outright.
- Interactive forms you still need people to fill in.
- Anything where the file size matters more than the next twenty years, because embedding every font makes files larger.
The honest summary: PDF/A is a preservation format, and preservation is a specific requirement rather than a general virtue. Converting routine documents to it adds size and removes capability in exchange for a guarantee you will never need.
How to produce one
This site cannot make a PDF/A file, and saying so is more useful than pretending otherwise.
The reason is structural rather than a missing feature. Producing valid PDF/A means embedding complete font programs, writing conforming colour profiles, and generating conforming metadata — then validating the result against the standard. That is a job for software built for it.
The realistic routes:
Export directly from the source. Most serious word processors and layout applications offer PDF/A in their export or “Save as PDF” options, sometimes under an Advanced or Standards button. This is by far the best route, because the source document still has everything the format needs.
Convert with desktop PDF software. Full PDF applications have a conversion and validation function that reports exactly which rules a file breaks.
Use an institutional tool. If an archive or portal is requiring PDF/A, it frequently publishes or recommends a validator, and that validator is the one whose verdict counts.
Validate before you submit. A file described as PDF/A and a file that passes validation are not always the same thing. If the portal offers a checker, use it before the deadline rather than after.
For scanned documents specifically
There is a wrinkle worth knowing if your archive is paper-derived.
A scan is a picture, and a picture carries no text. Archiving it as an image alone produces a document nobody can search — which defeats much of the point of archiving it. The PDF/A profiles intended for scans expect the page image to be accompanied by a recognised text layer, so the document is both a faithful reproduction and searchable.
That is exactly the two-layer arrangement OCR PDF produces: the scanned image untouched, with an invisible transcript positioned over it. Running recognition is therefore a genuine step towards an archival scan even though the conversion itself happens elsewhere — how OCR makes a scanned PDF searchable covers what to expect from it.
Two things to get right first, because the archive will keep whatever you give it: capture at 300 DPI greyscale, and check the scan is legible before recognising it. A blurry scan preserved for forty years is forty years of a blurry scan.
How to tell whether a file you were sent is already one
Sometimes the question is not how to make one but whether the document in front of you already qualifies.
Most readers announce it. Open the file and look for a bar across the top of the document area saying it is a PDF/A file and that the reader has switched to a viewing mode. That banner is the quickest answer available.
Check Document Properties. Under the description or standards section, a conforming file usually names its exact version and level — “PDF/A-2b” rather than just “PDF/A”.
Neither is proof. A file can carry metadata claiming conformance without actually conforming, because the claim and the content are written separately. If it matters — a submission that will be validated, an archive deposit that can be rejected — run it through a real validator rather than trusting the label.
The practical rule: treat the banner as a good sign, treat Document Properties as a claim, and treat a validator’s verdict as the answer.
The order to work in
If a document is heading for an archive, the sequence matters and it is the reverse of what people usually do.
Finish the document completely first. Assemble it, get the page order right, remove what is surplus, number it. Every one of those operations rebuilds the file, and rebuilding after conversion can break conformance.
Then check what is inside it. Archives keep metadata as faithfully as content, including the author field and any comments you have stopped seeing — what hidden data your PDF carries covers finding those.
Then convert and validate. Last, once nothing else will touch the file.
And note the collision with security: since PDF/A forbids encryption, a document that must be both archived and transmitted securely needs two copies — the archival one, and a protected one for sending.
Why the standard exists at all
It is worth appreciating what problem this solves, because it is not obvious until you have met it.
Digital documents fail silently. A file opens, renders, and looks broadly right while a substituted font has shifted a table, a colour has drifted, or a form field renders empty. Nothing announces the change. Ten years later there is no way to know what the document originally looked like, and no original to compare against.
PDF/A exists so that a document can be checked rather than trusted: a validator can state that a file conforms, and conformance means the file carries its own rendering. That verifiability is the product. Everything the format forbids is the price of it.