PaperKit

PDF to PDF/A

PDF/A embeds fonts and colour profiles so the document renders identically decades from now — required by many courts, registries and archives.

Drop your file here

Processed server-side: streamed through, never stored

Private: files never leave your device

PDF/A is the ISO-standardised subset of PDF intended for long-term archiving, and converting to it makes a document self-contained: fonts embedded, colour profiles included, and everything that depends on the outside world removed. The point is that the file should render identically in twenty years on software nobody has written yet — which an ordinary PDF cannot promise, because it may rely on fonts installed locally or content fetched over a network. Courts, land registries, national archives and regulated submissions commonly require it for exactly this reason. The conversion runs on our server, since validating and rebuilding a document to the standard needs a document engine: the file streams through and the PDF/A streams back, with nothing stored, though it does leave your device. Expect the file to grow, because self-contained means carrying everything it needs.

What the standard forbids

PDF/A removes anything whose rendering could depend on the environment. JavaScript, embedded audio and video, external content references and encryption are all excluded, and transparency is restricted in the stricter conformance levels.

Fonts must be embedded — no exceptions, including the ones every reader is assumed to have — and colour must be defined by an embedded profile rather than left to the device. Together these make the file a closed system: everything needed to draw the page is inside it.

The conformance levels

PDF/A-1b is the baseline: the document will look right. PDF/A-1a adds structural tagging so the reading order and semantics are recorded, which is what makes a document accessible as well as durable.

Later parts, PDF/A-2 and PDF/A-3, permit newer PDF features such as transparency and, in the case of A-3, embedded source files. Which level you need is dictated by whoever is asking for it, and it is worth confirming rather than assuming — a submission rejected for the wrong conformance level is a slow way to find out.

Practical consequences

Files get larger. Embedding fonts that were previously assumed, and colour profiles that were previously implied, adds weight — sometimes substantially on a document using several typefaces.

Some content cannot be converted without changing it. Encrypted documents must be decrypted first, since PDF/A forbids encryption. Interactive elements and multimedia are dropped rather than preserved. And a scanned PDF converts happily to PDF/A while remaining unsearchable — the standard governs durability, not whether there is any text in the file.

Frequently asked questions

How are my files handled?

This conversion needs a rendering engine that browsers do not have, so the file is processed on our server: it is streamed through the converter and the result is streamed back — nothing is stored, and files are discarded the moment the response is sent.

Why is my PDF/A file bigger than the original?

Because it now contains everything it needs to render itself: every font fully embedded, plus colour profiles. That self-sufficiency is the entire point of the format, and the size is what it costs.

Does converting to PDF/A make a scan searchable?

No. PDF/A governs long-term renderability, not content. A scanned page converts to a PDF/A that is still an image of text — run OCR if you need it to be searchable.

Which conformance level do I need?

Whichever the body asking for it specifies — commonly PDF/A-1b for appearance or PDF/A-1a where tagged structure and accessibility are required. Confirm rather than guess; a submission rejected on conformance level is a slow round trip.

More PDF tools

Advertisement