What PDF/A actually guarantees, and when it is worth the trouble

The four dependencies PDF/A removes

An ordinary PDF can lean on four things that live outside the file. Each is a way for a document to look right today and different — or fail to open — later.

• Fonts it names but does not carry. A PDF may reference a font and assume the reading machine has it. If it does not, the reader substitutes whatever it has and the layout shifts. When the substitute lacks the glyphs entirely, the page fills with empty rectangles and the document is unreadable even though nothing is corrupt.
• Colours it describes but does not define. "Thirty per cent cyan" only means something if you know whose cyan. Without an embedded colour profile, the same numbers land differently on every device, and a brand colour or a product photograph drifts a long way from what was approved.
• Content it points at instead of containing. External streams, linked images and referenced attachments are all legal in a normal PDF. An archive copy has to be self-contained, so anything it merely points at becomes a broken reference the moment the target moves.
• Behaviour it runs. JavaScript, form calculations, embedded media and encryption all make a document depend on software and passwords that may not exist in thirty years. In an archive, a password is a lock whose key is somebody's memory.

None of these is a defect. Each is a useful feature in a working document. PDF/A is not arguing that they are wrong — it is saying an archive has a different job: the file must be readable by software, and by people, who have never heard of the application that produced it.

What conformance actually constrains

The standard does not describe a better PDF. It describes a narrower one: the existing format with rules that remove every dependence on the outside world.

• Every font used must be embedded. Naming a font is not enough; the glyphs have to travel with the document.
• Colour must be device-independent, tied to an output intent or an embedded ICC profile so the numbers mean the same thing on any device.
• Encryption is not permitted. A conforming file is readable by anyone who holds it, which is the point for an archive.
• Executable content is not permitted: no JavaScript, no embedded media players, no external actions.
• All content must live inside the file — no external streams and no references to objects that are not part of the document.
• Metadata must be present and structured as XMP, and the file must declare which part and level it claims to satisfy.
• The file structure itself must follow the format rules exactly, a requirement that sounds bureaucratic until you have tried to parse a PDF that does not.

Two consequences follow immediately. A conforming file is usually larger, because fonts that were once merely named are now carried in full. And a conforming file is often a converted file: most documents are not born compliant, they are corrected afterwards and checked by something other than the tool that produced them.

Parts and levels: which one to ask for

PDF/A is a family rather than a single specification. The part number roughly tracks the era of PDF it is built on; the level letter says how strict it is about extracting and navigating the text.

The level letter is independent of the part. Level b guarantees the visual appearance. Level u adds the requirement that all text carry Unicode mappings, so it can be extracted and searched reliably. Level a goes further and requires tagged structure, so the document can be read aloud in a sensible order and navigated with assistive technology. Most requests in practice are for b, because it is the cheapest to reach and appearance was what archives were originally worried about.

If someone asks for "PDF/A" without naming a part, PDF/A-2b is the safe modern default. Do not volunteer A-3 unless you genuinely need to embed something: the extra permission is also an extra rule for a validator to test.

What it costs

Compliance is bought with features. Before converting a working document, know what you are giving up.

• File size. Full font embedding plus an ICC profile routinely adds tens or hundreds of kilobytes, and far more for documents in non-Latin scripts. A 300 KB file becoming 2 MB is normal, not evidence of a bad converter.
• Transparency, under A-1. If the source uses transparent objects they must be flattened. The page looks the same, but it is now a single blended layer, and whatever sat behind a semi-transparent panel is no longer separately present.
• Encryption. A conforming file cannot be password protected. If confidentiality matters it has to be handled by controlling who can reach the file, not by locking the file itself.
• Interactive behaviour. Form fields may survive, but calculations and validation scripts do not. A conforming form is a printed form.
• Layers. Optional content cannot survive into A-1, so a drawing with hidden layers becomes one fixed view.

There is a second, less obvious cost: a converted file is no longer the original. If you may later need to show what was actually written and signed, keep the original beside the archive copy. An archive is for reading in the future, not for proving what happened in the past.

How to check a file, and how not to be fooled

The XMP metadata carries the claim — look for an entry in the PDF/A identification namespace giving the part number and conformance level. It is easy to read, and just as easy to write without meaning anything.

• Open the file's document properties and look for a line naming PDF/A and a part number; many readers display the identification directly.
• Treat that as a self-declaration. A converter can write "PDF/A-2b" into the metadata whether or not the file satisfies the rules, and most readers will repeat it back without checking a single object.
• To actually verify, use a validator. veraPDF is the open-source reference implementation built for precisely this, and it reports the specific clause each failing object breaks instead of a bare pass or fail.
• Commercial tools offer the same capability under names like Preflight. What matters is not the brand but whether the tool reports per-rule findings you can act on.
• If a file fails, the usual causes in order are a font that was named rather than embedded, a device-dependent colour space with no output intent, and leftover JavaScript or attachment objects.

A practical rule: never accept a PDF/A claim from the tool that produced it. The declaration and the reality are two separate things, and only one of them is checked.

What you can still do locally

One tool on this site touches the font question, and it is worth being precise about how, because it looks like a shortcut to compliance and is not one.

Converting text to outlines replaces each glyph with its drawn shape. Nothing needs embedding any more, because there is no text left to embed — the letters are vector graphics now. That genuinely removes the font-dependency problem. It also removes the text layer permanently: an outlined document cannot be searched, copied from or read aloud, which is exactly what levels u and a exist to protect. Most archives will reject a text document with no text in it.

• Normalise page sizes and remove stray or blank pages before the file reaches a validator, so the conformance report is about the rules rather than about a misfed sheet.
• Avoid lossy compression on anything destined for archiving. Rendering pages to images and re-encoding them destroys the text layer and drops image quality below what a repository expects.
• Read the metadata rather than assuming it is empty. Knowing what a document actually carries is the first thing to check before handing a file to an archive.
• Keep the untouched original. Whatever you convert, the source is the only copy whose provenance is intact.

So outlining is useful for other reasons — sending a design to a print shop that lacks your fonts, or freezing a layout before a handover — but it is not a route to PDF/A, and a site that told you otherwise would be selling you a file that fails on first inspection.

What the tools here can honestly contribute is the preparation around the edges:

A short checklist before you archive anything

• Identify what is actually being asked for: PDF/A-1b, A-2b, A-2u, A-3. The differences change what you have to give up.
• Keep the source file. Never archive a conversion as though it were the original.
• Embed the fonts, or verify that the application that produced the file did.
• Remove passwords, JavaScript and anything that depends on a network being reachable.
• Declare the identification in XMP, then verify with a validator that did not produce the file.
• Record, somewhere outside the PDF, what you did and when. A file that cannot be explained is a file that cannot be trusted.