What is PDF/A and when do you actually need it?

Someone has asked you for a PDF/A file. Possibly a court's filing portal, possibly a records manager, possibly a university deposit system — and probably without explaining what the difference is or why it matters. The reassuring part is that PDF/A is not a new format you have to learn. It is ordinary PDF with the unreliable parts taken out.

The less reassuring part is that the restrictions are strict enough that most PDFs already in circulation do not satisfy them. That is why conversion is a real processing step and not a rename.

What PDF/A actually is

PDF/A is defined by ISO 19005, first published in 2005. It is not a separate file type: a PDF/A file still ends in .pdf, still opens in any reader you already have, and looks identical to the document it came from. What makes it PDF/A is that it obeys a documented list of restrictions — and declares in its own metadata which version of the list it follows.

The standard has been extended four times, and the parts are not interchangeable. Each one was written against the PDF specification of its day:

Alongside the part number, each file carries a conformance level — the letter you see in names like PDF/A-2b. The letter is a completely separate axis from the number, and confusing the two is the single most common misunderstanding about the standard:

• Level b (basic). The file will reproduce its own visual appearance reliably in the future. That is the entire promise — nothing is guaranteed about extracting or searching the text.
• Level u (Unicode). Level b, plus every character on the page maps to a Unicode value, so text can be extracted and searched dependably. Introduced with PDF/A-2.
• Level a (accessible). Level u, plus a tagged document structure: headings, tables, reading order and language, the information a screen reader needs to make sense of a page.

Almost everything asked for in practice is a b-level file, for a reason covered further down: levels u and a require information that a converter cannot invent if the source document never had it.

The rule everything else follows from

Every restriction in ISO 19005 exists to serve one requirement: the file must contain everything it needs to render itself, with no dependency on anything outside it. Not on a font installed on your machine, not on a colour profile your monitor happens to use, not on a server that resolves a link, not on a password somebody wrote down in 2026.

Once you accept that requirement, the rules stop looking arbitrary and start looking obvious:

• Every font must be embedded — and embedded with a licence that permits it. A file that references Helvetica and expects the reader to supply it is making a bet on a future computer.
• Colour must be defined absolutely, through an embedded ICC output intent, rather than left to whatever the display decides. Otherwise "this shade of red" means nothing in fifty years.
• Encryption is prohibited. A key is a dependency, and dependencies get lost.
• No JavaScript, no embedded audio or video, no launch actions. Behaviour that cannot be guaranteed to work is behaviour that cannot be archived.
• No references to external content. Everything displayed must live inside the file.
• Metadata must be present in XMP, in a documented, machine-readable form — including the declaration of which part and level the file claims.

What conversion changes in your file

Conversion is not a stamp applied to an unchanged document. Things are added, removed and rewritten, and it is worth knowing which before you replace an original:

The size increase catches most people out. A ten-page document that used only system fonts can grow noticeably once those fonts travel inside it. If the file also has to fit an upload limit, compress it first — compressing afterwards rewrites the file and will generally void the conformance you just paid for.

Claiming PDF/A vs conforming to it

Here is the distinction that decides whether your submission is accepted. The declaration that a file is, say, PDF/A-2b lives in that file's XMP metadata — and it is written by whichever program produced the file. Nothing stops a writer from stamping the claim and then emitting a document that breaks the rules.

So the question "is this file PDF/A?" has two different answers: what the file says about itself, and what an independent check of the ISO rules finds. A reader showing you a PDF/A badge is reporting the first. Submission portals check the second.

The reference validator is veraPDF — free, open source, developed under an EU-funded programme and backed by the PDF Association. It runs the full conformance check and reports failures rule by rule, naming the objects at fault rather than saying "invalid". Acrobat's preflight does the same job commercially. If a registry, court or regulator requires proof of conformance, validate the file yourself rather than trusting the badge in a viewer.

When you actually need it

PDF/A is worth the trade in a narrower set of situations than the marketing around it suggests. The genuine ones share a common thread: somebody other than you will need to open this document after the software that produced it is gone.

• Court and regulatory filing. Many electronic filing systems either require PDF/A or recommend it in their submission guidance, and reject files that fail validation.
• Institutional archives and records retention. National and university archives commonly specify a PDF/A part and level as their accepted deposit format.
• Theses and academic deposit. University repositories are among the most consistent users of the standard, because they are storing documents for the long term by definition.
• Documents with a statutory retention period. Contracts, audit files, tax records, employment and medical files that must remain readable for years by law rather than by preference.
• Hybrid electronic invoices. Formats such as Factur-X and ZUGFeRD are PDF/A-3 files carrying invoice XML inside a human-readable invoice page — one file that both a person and an accounting system can read.
• Patent and standards submissions. Bodies that keep permanent public records tend to specify the format they will keep them in.

If a requirement names a specific flavour — PDF/A-1b rather than "PDF/A" — treat that as binding. A valid PDF/A-2b file will be rejected by a system that demands PDF/A-1b, and the rejection message rarely explains why. Our companion article on choosing between 1b, 2b and 3b covers what actually differs.

When you don't

Most PDFs should not be PDF/A, and it is worth saying so plainly because a great deal of writing on this subject implies the opposite.

• Documents with a short life. An invoice you will delete after payment, a draft circulated for comment, a report read once — none of these need to survive a change of century.
• Anything that has to stay interactive. Forms driven by scripts, embedded media, calculated fields. The features that make those work are precisely the ones the standard removes.
• Files under a tight size limit. Conversion grows a file; a portal capping uploads at 10 MB may be the harder constraint.
• Design-heavy documents, if you are being told to use PDF/A-1. Flattening transparency changes how shadows, glows and blend modes render. PDF/A-2 keeps them.

PDF/A costs you file size and features, and buys you legibility decades from now. When nobody is going to read the document decades from now, there is no reason to pay.

The scanned-document trap

This is the failure that turns up years later, long after anyone can fix it cheaply. A scanned document converts to PDF/A perfectly happily and validates without a complaint — because a scan is a picture, and level b promises only that the picture will still display correctly.

What the archive receives is a compliant, permanent, entirely unsearchable file. Nobody notices at deposit time. It surfaces when someone needs to find every contract mentioning a particular clause across ten years of records, and the only way to do it is to open files one at a time and read them.

Strictly, a guarantee about text belongs to level u rather than level b, and no converter can promise that a b-level file is searchable. In practice, a b-level file with a good OCR layer behaves like a searchable document; a b-level file without one never will.

Convert a PDF to PDF/A in three steps

Converting with PdfDocShift takes about half a minute and needs no installation or sign-up. Uploads are permanently deleted from our servers after two hours.

How to check a file really is PDF/A

Five checks, in the order that catches problems fastest:

1. Read what the file claims. Acrobat shows a standards bar across the top of a PDF/A document; other readers list the standard in document properties. This tells you what the file says about itself, which is a start and not a verdict.
2. Validate against the ISO rules. veraPDF is free, open source, and reports failures rule by rule with the offending object named. This is the answer a submission portal will reach independently of yours.
3. Check the flavour matches the requirement. A perfectly valid PDF/A-2b file fails a system that demands PDF/A-1b. Validators report the part and level they found, so compare it with what you were actually asked for.
4. Check the fonts. Document properties → Fonts. Every entry should read Embedded or Embedded Subset. A single non-embedded font is the quickest sign a file was never converted at all.
5. Keep the source document. Conversion is lossy in the ways described above, and there is no reverse gear. Keep whatever you can regenerate the file from — the original PDF, or better, the document it was exported from.

One habit worth building into any process that produces archives: validate a sample rather than everything, but validate it at the moment of deposit. A conformance failure discovered on the day is a two-minute fix. The same failure discovered in an audit three years later is a project.

Frequently asked questions