Quick summary: PDF/A is not a different file format — it is a restricted profile of PDF designed so a document renders identically decades from now, on software that hasn't been written yet. If you archive records, submit regulatory filings, or preserve legal documents, understanding the three conformance levels (PDF/A-1, -2, -3) and what invalidates a PDF/A is what separates a compliant archive from one that fails an audit. This guide covers what each level permits, the common reasons conversion fails, and how to validate the result.
Why PDF/A exists at all
A regular PDF can do things that make it fragile over long time horizons. It can reference fonts that aren't embedded (so it depends on the reader having them), execute JavaScript, require a password, link to external resources, use proprietary encodings, and depend on color profiles that live elsewhere. Each of those is fine for a document meant to be read this week. Each is a liability for a document meant to be read in 30 years — the external font may be unobtainable, the script may be meaningless, the link may be dead.
PDF/A (ISO 19005) closes those holes by forbidding anything that depends on an external resource or future execution. A valid PDF/A is fully self-contained: everything needed to render it — fonts, color profiles, metadata — is embedded inside the file. The trade-off is size (embedded fonts and profiles add weight) and flexibility (some features you may want are disallowed). The payoff is permanence.
This is why courts, government archives, libraries, and regulated industries mandate PDF/A for records retention. It is not about looking nice today; it is about being openable and accurate when the software that created it no longer exists.
The three conformance levels, plainly
| Level | Standard | What it is | When you'd choose it |
|---|---|---|---|
| PDF/A-1 | ISO 19005-1 (2005) | The original. Strictest about transparency and image encodings. | When a regulator or counterparty specifically demands "PDF/A-1" — common in EU e-justice and some national archives. |
| PDF/A-2 | ISO 19005-2 (2011) | Newer, more practical. Allows JPEG and JPEG2000, transparency, larger files via PDF 1.7 features. | The sensible default for most modern archiving. Better image quality at smaller size than A-1. |
| PDF/A-3 | ISO 19005-3 (2012) | Like A-2, but allows embedding arbitrary files (the original source document, XML data, etc.) inside the PDF/A. | For workflows that need the human PDF and the machine-readable source bundled as one auditable object — e.g., e-invoicing (ZUGFeRD/Factur-X). |
Each level also has conformance levels (sub-classes): A (accessible — tagged, reflowable, machine-readable structure), B (basic — visual appearance preserved only), and U (Unicode text mapping, A-2 and A-3 only — text is searchable and extractable). For accessibility or screen-reader use, choose A. For "it must look right forever and be searchable," U is usually enough and easier to produce.
Practical default: if nobody has told you which level to use, produce PDF/A-2u. It is the modern sweet spot — searchable, reasonably strict, and widely accepted.
What makes a regular PDF non-compliant (the common blockers)
When conversion to PDF/A fails or produces a file that won't validate, it is almost always one of these:
- Unembedded fonts. The single most common cause. A compliant PDF/A must embed all fonts (or at least the subsets used). Documents authored with system fonts or stripped to save size frequently fail here.
- Encryption or password protection. PDF/A forbids encryption. You must decrypt first.
- JavaScript, interactive forms (AcroForm fields with actions), and multimedia. All disallowed. Form fields must be flattened.
- External references — links or resources pointing outside the file. Content must be self-contained.
- Unsupported image encodings or color spaces — particularly an issue for PDF/A-1, which is pickier than A-2/A-3.
- Missing or invalid XMP metadata — PDF/A requires an XMP metadata stream declaring its own conformance.
- Annotations or features that depend on execution (e.g., some annotation actions, 3D content).
The good news: a proper converter handles most of these automatically — embedding fonts, flattening forms, stripping disallowed features, and writing the required XMP metadata. The conversion step exists precisely to fix the things that make a normal PDF non-compliant.
How to convert to PDF/A
The reliable path is to convert from a clean source (a normal PDF or an office document) using a tool that performs true PDF/A normalization — embedding fonts, flattening, and writing the XMP conformance declaration. The PDF to PDF/A tool does this locally in your browser, which matters for archival records that are often also confidential (legal filings, medical records, financial statements — exactly the documents you don't want uploaded to a server).
Typical workflow:
- Start from a finalized source. Resolve all the content issues first; PDF/A freezes the document.
- Decrypt if needed. If the source is password-protected, remove the password (via Decrypt) before conversion — PDF/A can't be encrypted.
- Flatten forms and annotations if you don't need them interactive (via Flatten). Required form data should be flattened in so it's part of the permanent record.
- Convert to the chosen level (A-1, A-2, or A-3; conformance A, B, or U).
- Validate — see below. Conversion is not the same as verification.
How to validate a PDF/A (don't skip this)
A file named .pdf that claims to be PDF/A is not necessarily compliant — a converter can produce a file with violations if the source was problematic. For anything archival, validate independently after conversion.
What validation checks:
- All fonts are embedded.
- No encryption is present.
- No disallowed features (JS, external refs, etc.) remain.
- The required XMP metadata declaring the conformance level is present and consistent.
- The structure matches the claimed level's rules.
Validation tools (VeraPDF is the open-source reference validator for the ISO standard) read the file and report any rule violations. If you're producing PDF/A for a regulator, run the validator they specify — some mandate a particular tool or level. For internal archiving, any current PDF/A validator will surface the common problems above.
Frequently asked questions
Is PDF/A the same as a "flattened" PDF? No. Flattening merges annotations and form fields into page content. PDF/A is a conformance standard covering fonts, self-containment, and metadata. They're complementary: archival workflows often flatten and convert to PDF/A.
Can I edit a PDF/A afterward? Technically you can open and modify one, but doing so typically invalidates its compliance (you may un-embed a font or add a disallowed feature). Treat PDF/A as the final output of a workflow, not an intermediate. Edit the source, then re-convert.
Does PDF/A guarantee the document looks identical forever? It guarantees everything needed to render it is present and that no disallowed feature can break rendering. It does not guarantee pixel-identical rendering across every reader — that depends on the reader's implementation. But it removes the most common reasons a future reader would fail.
Is PDF/A bigger than regular PDF? Usually, yes — because fonts and color profiles must be embedded. The size increase depends on how much was already embedded. For text-heavy documents it's modest; for documents with many unembedded fonts it can be significant.
Why process archival PDFs locally? Because the documents most often archived under PDF/A — court filings, patient records, contracts, regulatory submissions — are exactly the ones you least want uploaded to a conversion server. Client-side conversion keeps the source and the output on your device.
Conclusion
PDF/A trades flexibility for permanence. Pick the level your regulator requires (PDF/A-2u if nothing is specified), start from a clean decrypted source, flatten what doesn't need to stay interactive, convert with a tool that does true font-and-metadata normalization, and validate independently before you file the result away. An archive that can't be opened is just expensive disk usage; PDF/A is how you make sure today's record is still tomorrow's evidence.
Convert a PDF to PDF/A — locally in your browser, nothing uploaded →
Related reading: