What PDF/A is, why your "normal" PDF probably isn't one, and how to check

Sooner or later a form asks for "a PDF/A", you upload the PDF you already have, and the portal rejects it. The file opens fine everywhere else, so the rejection looks arbitrary. It is not. PDF/A is a separate ISO standard (ISO 19005) that takes the ordinary PDF format and removes every feature that could stop the document from rendering identically in fifty years. Most PDFs produced day to day use at least one of those features, which is why "convert to PDF" and "convert to PDF/A" are different operations.

What the standard actually demands

A file that claims to be PDF/A has to be self-contained and unambiguous. In practice that means a fixed list of rules, and the rules explain almost every rejection you will ever see:

• Every font must be embedded in the file, including the standard fourteen (Helvetica, Times, Courier) that ordinary PDFs are allowed to leave out because "every viewer has them". Fonts must also carry the tables that map glyphs back to Unicode text, so the document stays searchable.
• No encryption of any kind. A password-protected PDF can never be PDF/A, because a future reader might not be able to open it. If you need both, the archive copy is the unprotected one.
• No JavaScript, no launch actions, no embedded audio or video, and no references to external files. Anything that needs something outside the file to work is forbidden.
• Colour must be defined in a device-independent way. A PDF that just says "print this in DeviceRGB" fails; it has to carry an ICC output profile that pins down what those RGB numbers mean.
• Transparency is forbidden in PDF/A-1, allowed from PDF/A-2 onwards. This is why files exported from PowerPoint or design tools, which use transparency constantly, so often fail the older level.
• The file must contain XMP metadata that declares which PDF/A part and conformance level it claims (for example "PDF/A-2b"). Without that declaration a validator will not even consider it.

Parts and levels: what "2b" means

The standard has been revised three times, and each revision is a "part". PDF/A-1 (2005) is based on PDF 1.4 and is the strictest: no transparency, no JPEG 2000, no layers. PDF/A-2 (2011) is based on PDF 1.7 and allows all three, plus embedding other PDF/A files inside it. PDF/A-3 (2012) additionally allows embedding arbitrary files of any type, which is what electronic invoicing formats such as ZUGFeRD and Factur-X use to ship an XML alongside the human-readable PDF. PDF/A-4 (2020) is based on PDF 2.0 and reorganises the levels.

The letter after the number is the conformance level. "b" (basic) guarantees only that the visual appearance is preserved. "a" (accessible) additionally requires the document to be tagged: a logical structure tree marking headings, paragraphs, tables and reading order, with alternative text for images. "u" (Unicode, from part 2) sits in between: text must map to Unicode but tagging is not required. When a portal asks for "PDF/A" without qualification, it almost always accepts 1b or 2b; when a public administration asks for accessibility, it means the "a" level, which is much harder to achieve.

Why a PDF exported from Word usually fails

Word's ordinary "Save as PDF" produces a compact, perfectly valid PDF that fails PDF/A validation for three predictable reasons. First, it does not embed the standard fonts if the document uses them, and it may subset others in a way that drops the Unicode mapping. Second, it declares colour as DeviceRGB with no output intent profile. Third, it does not write the XMP declaration. None of these are defects; they are the defaults of a format that assumes the reader has fonts and a screen.

Word does have a PDF/A option: in the save dialog, under Options, "PDF/A compliant" (on Windows) or "Best for electronic distribution and accessibility" (on macOS, which produces tagged PDF but not necessarily PDF/A). LibreOffice has a clearer checkbox, "Archive (PDF/A, ISO 19005)", with the part selectable. Both fix fonts, colour profile and metadata in one go. What none of them can fix is content that the standard forbids: if your document contains an embedded video or a form field with JavaScript, the exporter either strips it or refuses.

How to check a file without Acrobat

The reference validator is veraPDF, a free, open-source tool maintained by the PDF Association and the Open Preservation Foundation. It runs on Windows, macOS and Linux, takes a file or a folder, and produces a report listing every rule violated with the clause of the standard it corresponds to. If you have to deliver PDF/A regularly, it is the tool to keep. Its verdict is what most institutional portals use internally, so a file that passes veraPDF will pass the portal.

For a quick look without installing anything, the PDF's own metadata is a first signal: a PDF/A file carries a pdfaid:part and pdfaid:conformance entry in its XMP block. Any tool that shows document properties will surface it; Acrobat Reader displays a blue "This file claims compliance with the PDF/A standard" banner. Note the word claims: the declaration is just a statement, and a file can declare PDF/A while violating the rules. Only a validator confirms it.

What happens if you edit a PDF/A

This is the part that catches people. PDF/A is a property of the whole file, and almost any modification can break it. Merging a PDF/A with a non-PDF/A document produces a non-PDF/A document, because the imported pages bring their non-embedded fonts and device colours with them. Adding a password breaks it by definition. Adding a watermark with a font that is not embedded breaks it. Even harmless-looking operations such as rotating pages can leave the file technically valid but with the XMP declaration now stale.

The safe workflow is therefore: do all editing on the ordinary working copy, and produce the PDF/A as the very last step from a tool that knows the standard. The tools on this site operate on the ordinary format; they will not turn a file into PDF/A and, for merge, split, organize and rotate, they preserve embedded fonts and images so a subsequent PDF/A conversion has less to fix. But treat the output as a working copy, never as the archive copy.

When you do and do not need it

You need PDF/A when a third party requires it: court filings in many jurisdictions, land and company registries, university thesis deposits, public tenders, long-term records under regulations such as those for pharmaceutical or financial archives. You also want it for anything you intend to keep for decades where "opens on my current laptop" is not a sufficient guarantee.

You do not need it for a document you will email tomorrow and forget. PDF/A files are larger (every font embedded, no encryption, often no aggressive image compression), they cannot carry the interactive features that make forms useful, and the "a" level in particular takes real effort to produce. Making everything PDF/A "just in case" trades convenience for a guarantee you may never cash in. Make the archive copy when there is something to archive, and check it with a validator before you send it.