What PDF/A actually requires

PDF/A is a checklist, not a button, and most "convert to PDF/A online" tools quietly skip the hard items on it. The standard exists so a document opens and looks identical decades from now, on software nobody has written yet — and buying that guarantee means embedding every font, pinning down colour with a reference profile, banning encryption, and making the file entirely self-contained. Some of those a browser can honestly do. Two of them it cannot, and a tool that claims otherwise is selling you a label, not conformance.

PDF/A is defined by an ISO standard (ISO 19005). The point of it is longevity: an archived document must not depend on anything outside itself, because in twenty years the fonts, the colour assumptions and the network resources it once relied on may all be gone. Everything the standard demands flows from that one requirement — the file has to carry everything it needs to render itself.

Every font has to be embedded

A conforming PDF/A file must embed every font it uses. This is the same problem as why a PDF looks different on someone else's screen: a file that merely names a font is trusting the reader's computer to have it, and an archive cannot make that bet. So the standard requires the actual font data to travel inside the document. The catch, for a browser tool, is that you cannot reliably guarantee this for an arbitrary uploaded PDF. Checking whether every font is fully embedded — and embedding any that are not, correctly, with the right subset — is a whole font pipeline the tool would have to run, and doing it wrong produces a file that claims conformance and fails validation.

Colour has to be device-independent

PDF/A also requires a defined colour basis: an OutputIntent carrying an embedded ICC profile, so that "this shade of red" means one specific measurable colour rather than "whatever red this device happens to produce". Without it, the same page can render in visibly different colours on different screens and printers — the exact drift an archive is meant to eliminate. Fabricating a correct profile for a document from inside a browser is not something a tool can do responsibly, because a wrong profile is arguably worse than none: it asserts a colour meaning the document never actually had.

On top of those two, the standard forbids encryption entirely, disallows reliance on external files or fonts, and bans features like embedded JavaScript. It also wants XMP metadata that records which conformance level the file claims. Some of that list is genuinely within reach of a browser.

What our tool honestly does

Our PDF to PDF/A tool does the archival cleanup it can stand behind, and does not pretend to the rest. It refuses password-protected input, because PDF/A forbids encryption and a permission-restricted file is decrypted and saved out clean rather than turned away. It fully re-serialises the document through the PDF library, which normalises the file structure. And it sets clean, explicit document metadata — producer, creator and dates. What it does not do is embed an ICC OutputIntent profile or guarantee that every font is embedded, so it is not a certified ISO PDF/A-1B converter, and the tool says exactly that rather than stamping a badge it did not earn.

The reason to tell you all this rather than ship a green checkmark is that the checkmark would be the lie. An archive you cannot trust is worse than no archive, because you stop keeping the original. If a document genuinely has to survive for decades, it is worth doing to a standard that can be validated — and worth knowing that the free browser step is preparation, not certification. For the tidy-metadata half of the job, editing the metadata directly and stripping any stale second copy is the honest, verifiable part you can rely on.

There is more than one PDF/A

"PDF/A" is not a single target either, which is one more reason a one-button converter oversimplifies. The standard has several parts — PDF/A-1, -2 and -3 — and conformance levels within them: level B, for "basic", guarantees the visual appearance is preserved, while level A, for "accessible", additionally requires a tagged structure so the reading order and meaning are machine-readable. Later parts relax some of the original rules — PDF/A-3, for instance, permits embedding other files, which the first part forbade. Which one an archive requires depends on who is keeping it and why, and confirming a file actually meets it is a job for a validator, not a badge the converter awards itself.

None of this makes the browser step useless — it makes it honest about what it is. A re-serialised, unencrypted PDF with clean metadata is a genuinely better starting point for archiving than the file you began with: it has no password to lock a future reader out, its structure has been normalised, and its producer and dates say what they mean. That is preparation an archivist can build on, and it is exactly the part that can be done reliably from inside a browser.

The line the tool will not cross is the label. Stamping "PDF/A" on a file whose fonts have not been verified and whose colour has not been pinned down would make it claim a conformance it does not have — and the cost of that lands later, when the file fails a validator or, worse, renders wrong in the decade nobody is checking. A false archival guarantee is the one kind of wrong claim that does its damage precisely when it is too late to fix, which is why the tool reports what it did rather than what you were hoping it did. An honest description of the cleanup you can build on beats a conformance badge you cannot trust.

• PDF/A (ISO 19005) requires embedded fonts, a device-independent colour profile, no encryption, and a self-contained file.
• A browser cannot reliably guarantee full font embedding or fabricate a correct ICC profile for an arbitrary PDF.
• Our tool does the honest subset: refuse encryption, re-serialise, set clean metadata — labelled "not certified PDF/A".
• For real conformance, use dedicated software and validate with a tool like veraPDF.