The first time a national archive, a court filing system or a records department bounces your PDF, the rejection notice is rarely helpful. The file opens. It prints. It looks exactly as it should. And yet it is not acceptable, because it is a PDF and what was asked for was PDF/A.
The distinction is worth understanding properly, because PDF/A is not a rival format and not a newer version of anything. It is a deliberately narrowed subset of PDF, published as ISO 19005, and every restriction in it exists to answer one question: will this file still render identically in fifty years, on software nobody has written yet, on a machine that has none of your fonts and no access to your network?
PDF’s flexibility is exactly the problem
An ordinary PDF is a set of drawing instructions plus a bag of resources those instructions refer to. Crucially, some of those references are allowed to point outside the file.
A font can be named rather than embedded, on the assumption that the reader’s system has it. A stream can carry a file specification pointing at content stored elsewhere. A page can carry JavaScript, a launch action that starts another program, or an embedded video that needs a codec. Colour can be specified in device terms, meaning “whatever this particular printer thinks red is”. The document can be encrypted, so opening it depends on a password somebody has to still know.
Every one of those is a legitimate PDF feature and a reasonable thing to do in a document that will be read next week. Every one of them is a dependency on the outside world, and archives deal in decades. A file whose appearance depends on your installed fonts is not a record; it is a request to reconstruct a record.
What PDF/A actually forbids
The rules fall into four groups, and once you see the grouping the list stops feeling arbitrary.
Nothing may live outside the file. Every font used must be embedded, including the base fourteen fonts that ordinary PDF lets you assume are always available; PDF/A grants them no exemption. Streams may not reference external content. Links to other documents are still allowed, since a link is a suggestion rather than a rendering dependency, but content is not permitted to arrive from elsewhere at display time.
Nothing may execute. No JavaScript, no launch actions, no embedded multimedia requiring a codec to play. An archived document is a record, not an application, and an interpreter that no longer exists renders an application unreadable.
Colour must be unambiguous. Device-dependent colour spaces may only be used when the file also carries an output intent with an embedded ICC profile, so that “this grey” has an objective definition rather than depending on the rendering device.
The file must describe itself. An XMP metadata packet is mandatory, and it must declare which part of the standard and which conformance level the file claims. Encryption is forbidden outright, because a document nobody can open is the opposite of an archive. Compression is restricted to methods the standard names, which is why the venerable LZW filter is not permitted anywhere in PDF/A while Flate is.
Then there are the version-specific prohibitions, which is where most confusion about “PDF/A” as a single thing comes from.
Four parts, and what each of them changed
- PDF/A-1, ISO 19005-1, published 2005, profiles PDF 1.4. It is the strictest by a wide margin: no transparency, no optional content layers, no embedded files at all.
- PDF/A-2, ISO 19005-2, published 2011, profiles PDF 1.7 as standardised in ISO 32000-1. It relaxes the big three: transparency is allowed, layers are allowed, JPEG 2000 becomes a permitted compression method, and embedded files are permitted provided they are themselves PDF/A. It also adds a conformance level, the middle one, u, which part 1 has no equivalent of.
- PDF/A-3, ISO 19005-3, published 2012, differs from part 2 in essentially one respect, and it is a significant one: an arbitrary file of any type may be embedded. This is why electronic invoicing standards attach a machine-readable XML payload to a human-readable PDF/A-3 document.
- PDF/A-4, ISO 19005-4, published 2020, profiles PDF 2.0 as standardised in ISO 32000-2. It also retires the letter-suffix conformance levels in favour of a single base level plus PDF/A-4f for embedded files and PDF/A-4e for engineering data.
If an institution simply says “PDF/A”, it usually means PDF/A-1b or PDF/A-2b. If it names a part and a letter, take the letter seriously, because it changes what the document has to contain rather than just what it may not.
The conformance levels are about words, not looks
Within parts 1 to 3, the letter is the load-bearing part of the requirement. Which letters exist depends on the part, and this catches people out: ISO 19005-1 defines exactly two conformance levels, a and b. The middle level, u, arrived with ISO 19005-2 in 2011, so PDF/A-1u is not a thing you can ask an archive for. Parts 2 and 3 offer all three.
Level b, for basic, promises only that the page can be reproduced visually. That is all. A page consisting of a single scanned photograph of a typed letter satisfies it completely.
Level u, available from part 2 onwards, adds that every character of text in the file maps to Unicode. This sounds like a technicality and is not: a PDF can quite easily contain text that draws correctly while carrying no reliable information about which characters those glyphs are, which is precisely why copying text out of some PDFs produces gibberish. Level u is the guarantee that extraction works.
Level a, for accessible, adds tagged logical structure: a real reading order, headings marked as headings, tables marked as tables, alternate text for images. It is by far the hardest to reach retroactively, because the information mostly has to come from the authoring application rather than being inferred afterwards.
You can find out quickly which side of the u boundary a document falls on. Running it through a PDF text extractor either gives you the words or, when it finds no usable text layer, hands back a short written notice saying so and pointing you at OCR, rather than an empty file that would leave you guessing whether the tool had failed. That notice is your answer: the document is an image-only scan, and no amount of conversion will make it level u or a on its own.
Which everyday edits break conformance
This is the part worth internalising if you handle documents that later go to an archive, because several perfectly sensible operations quietly disqualify a file.
Stripping metadata does. PDF/A requires that identifying XMP packet. A metadata remover deletes exactly that: it empties the document information dictionary and removes the catalogue’s XMP stream entirely, including the underlying object so the bytes are genuinely gone rather than merely unreferenced. That is the right behaviour for privacy and precisely the wrong behaviour for archival conformance. Strip first and convert afterwards, never the reverse.
Aggressive compression does. The heavy mode of a PDF compressor rasterises each page, re-encodes it as a JPEG at a fixed resolution, and rebuilds the document around those images. The result is smaller and visually similar, but every glyph has become a picture of a glyph. Whatever level of text mapping the original had is gone, so a level u or a document is demoted to something that can at best reach level b. Its lighter mode, which only re-serialises the existing objects, also drops the XMP stream, so it too costs conformance even though it never touches a pixel.
Flattening a form generally helps. PDF/A requires that annotations and form fields carry their own appearance streams and forbids relying on the reader to generate them. Running a filled form through a form flattener converts the interactive fields into ordinary static page content, which removes the whole category of problem: there is no widget left whose appearance a future reader might have to guess at.
Adding OCR helps the reader, but does not certify the file. Making a scan searchable means placing recognised words back over the image as text drawn in the invisible text rendering mode, so it is selectable and findable without being visible. That is exactly what a PDF OCR tool does. Be aware of one detail if the destination is an archive: the invisible layer here is written using one of PDF’s base fourteen fonts, which are referenced rather than embedded, and PDF/A does not exempt them. The searchable output is genuinely more useful, but it is not archival by construction, and a proper PDF/A conversion afterwards would need to embed that font.
A practical order of operations
If a document is heading for long-term storage, do the destructive and structural work first and the conformance conversion last, because conversion is the step that writes the metadata everything else would strip.
Scan or export at the resolution you actually want, since PDF/A has no opinion about image quality and will faithfully preserve a bad scan forever. Add the text layer. Flatten anything interactive. Remove whatever metadata is genuinely sensitive. Only then convert to the part and level you were asked for, and validate the result rather than assuming it, because the difference between a file that conforms and a file that merely looks like it does is invisible until an archive tells you about it.
