PDF/A is an ISO-standardised subset of PDF — ISO 19005, first published in 2005 and now in its third revision — built for one purpose: making sure a document opens correctly not just today but in twenty or fifty years, regardless of which software or operating system is reading it. A regular PDF is allowed to depend on things outside the file itself. It can reference a font installed on the system that created it rather than carrying the font data. It can be encrypted with a password tied to a piece of software's specific implementation. It can embed JavaScript that assumes a particular PDF reader and version. Every one of those dependencies is a way the file can quietly stop working once the surrounding software environment moves on. PDF/A closes each of those gaps by requiring the file to be fully self-contained.
The practical requirements are specific. Every font used anywhere in the document must be embedded in the file itself, not referenced by name. Any color used must be tied to an embedded ICC color profile so it renders the same way on any device, rather than relying on a generic RGB or CMYK assumption that varies between systems. The file cannot be encrypted or password-protected, because a password scheme is itself a piece of software logic that may not exist in future readers. JavaScript, embedded audio and video, and other forms of active content are prohibited outright since they depend on runtime features rather than static, inspectable data. And the file must carry an XMP metadata packet that explicitly declares which conformance level it meets — this is the label a validator or archive system checks first.
There are several conformance levels, and they are not interchangeable. PDF/A-1b (based on PDF 1.4) only guarantees that the document looks the same when reopened — visual fidelity, nothing more. PDF/A-1a adds a requirement for tagged structure, meaning the file must also carry accessibility information about reading order and semantic structure, which typically has to be built into the document from the source application rather than added afterward. PDF/A-2 and PDF/A-3 build on newer PDF versions and add support for things like transparency and, in the case of PDF/A-3, embedding non-PDF files inside the archival file — useful for keeping an invoice's original XML data attached to its PDF representation. Most day-to-day archival requirements ask for PDF/A-1b or PDF/A-2b specifically because they are the most widely validated and supported levels.
Who actually requires this rather than just recommending it: federal and state court e-filing systems in the US and equivalent judicial portals elsewhere often reject non-PDF/A submissions outright. Government records agencies, national and university libraries doing long-term digital preservation, and regulated industries like healthcare and financial services that have statutory retention periods measured in decades all specify PDF/A in their document-intake standards. If you have ever had a court filing bounced back for the wrong PDF format, or been told by a records department that your discovery documents need to be in "archival format," this is the standard in question.
One honest limitation worth stating up front: converting a file to declare PDF/A conformance and having it *actually* meet every requirement of the standard are two different things, and the gap between them is almost always fonts. If your source PDF already has all its fonts embedded — which is the default in most modern PDF-creation software — conversion here gets you a genuinely compliant file. If the original PDF referenced a system font without embedding it, no browser-side tool can retroactively embed font data that was never included in the file to begin with; the font simply isn't there to embed. In that case the only real fix is regenerating the PDF from its source document with font embedding turned on, then running the archival conversion again.
If your file is password-protected, run it through Unlock PDF first, since encryption is stripped during PDF/A conversion regardless.