PDF/A is a subset of PDF defined by ISO standard 19005. The 'A' stands for archival. A PDF/A file is self-contained: all fonts are embedded inside the file, all colour profiles are included, and the file does not reference any external resources. Open a PDF/A file in ten years on a machine that has never seen the original fonts or software, and it will render exactly the same.
Regular PDFs can contain references to external fonts, scripts that execute when the file opens, and links to external content. Those dependencies can break over time. PDF/A eliminates them at the point of creation.
When PDF/A is required
Courts, government agencies, and regulated industries often require PDF/A for formal submissions. If you are filing a document with a public registry, submitting to a court, or depositing files with a national archive, the specification will likely say 'PDF/A-1b' or 'PDF/A-2b.'
Document management systems that need to guarantee future readability also require PDF/A. Long-term storage in sectors like healthcare, finance, and law means files need to be readable for decades, not just until the software that created them is updated.
PDF/A-1b vs PDF/A-2b
PDF/A-1b (ISO 19005-1, 2005) is the original standard. It is the most widely supported and required by the oldest compliance systems. Limitations: no transparency, no JPEG 2000, no embedded files.
PDF/A-2b (ISO 19005-2, 2011) is a more modern revision. It supports transparency, JPEG 2000 compression, embedded PDF/A files, and digital signatures. It is accepted by virtually all systems that accept PDF/A-1b and is a better choice for documents created in the last decade.
PDF/A-3b (ISO 19005-3, 2012) adds one thing that matters in practice: it is the only level that permits files attached to the document. Beside each of those sits a level U — 2u and 3u — which adds a single further requirement: every character the page draws must be recoverable as text. A level B file is guaranteed to still look right; a level U file is also guaranteed to still be searchable and copyable, which is usually the point of archiving a document rather than a picture of one. Filum offers 1b, 2b, 2u, 3b and 3u, and checks your document before you choose — a level it cannot reach is greyed out with the reason, because conformance is partly a property of the input. A file that uses transparency cannot be PDF/A-1b however well it is converted, and a file whose font carries no character map cannot reach level U, however well it is converted. Level A (1a, 2a, 3a) is not offered, and that is deliberate: it requires tagged logical structure, reading order and alternative text that cannot be reconstructed from an untagged PDF, and a tool that generated them would be shipping an accessible-looking document that is not accessible.
What the conversion actually does
Converting to PDF/A is not simply adding metadata. Every font has to be stored inside the file, an ICC colour profile has to be attached as an output intent, an XMP packet has to declare the conformance level, and the document information has to agree with that XMP exactly. Anything the standard forbids — JavaScript, launch actions, encryption — has to go.
The hard part is fonts. Many PDFs, especially older ones, only name a font like Helvetica or Times and rely on your reader to supply it. There is nothing in the file to embed, so a metrically matched replacement is embedded instead: Liberation Sans for Helvetica and Arial, Liberation Serif for Times, Liberation Mono for Courier. These are open-licence faces whose letter widths match the originals, so lines break exactly where they did before — measured at zero point of positional drift. The letterforms themselves are drawn slightly differently, which is a visual change, not a layout one.
There is a detail here that decides whether the output is genuinely valid. The width table written into the file must match the font actually embedded, not the font originally named. Keeping the original widths produces a file that renders perfectly and fails validation — which is the worst possible outcome, because it looks like it worked. Filum writes the widths from the substitute's own measurements, and every font it replaces is named on screen before you convert.
File handling
The conversion runs entirely in your browser, on your own device. The file is never uploaded and never reaches a server. The substitute fonts and the sRGB colour profile are served from filum.se itself, so no third party sees a request either.
One honest limitation: your individual file cannot be validated on your device. Proper PDF/A validation means running a validator such as veraPDF, which is a Java program with no browser equivalent. So Filum will never tell you your file 'is valid PDF/A'. It tells you what level the output declares; what it confirmed by reading the result back — that every font is embedded, and that the fonts whose program and encoding it can read declare widths matching the font actually embedded; and that the converter itself is checked against the veraPDF reference validator over a committed corpus of test documents, at every level offered — 24 of 24 passed on 2026-09-02. The width check is reported as a count rather than a blanket claim, because it does not cover every possible font, and saying otherwise would be the same overclaim this paragraph exists to avoid.