PDF/A explained: when archives and courts require it

What PDF/A actually is

PDF/A is an ISO standard — a stricter subset of the regular PDF specification, purpose-built so a file will still open correctly decades from now, on software that does not exist yet. Regular PDFs are allowed to depend on things outside the file: linked fonts installed on your system, external content, encryption, embedded JavaScript. PDF/A forbids most of that.

A PDF/A file has to be self-contained. Every font used must be embedded inside the file, not just referenced by name. Encryption is not allowed, because a password today could become an unopenable lock decades from now once nobody remembers it. Certain color spaces and metadata requirements are also enforced, all in service of one goal: a file that a future reader can open with confidence.

Who actually requires it

Federal and many state court e-filing systems require PDF/A for at least some filings, precisely because court records need to remain readable for the life of a case — which can be decades. National archives, some government record-keeping systems, and certain regulatory or compliance filings carry the same requirement.

If nobody has told you PDF/A is required, you probably do not need it. Everyday business documents, invoices, contracts sent for signature, and personal paperwork almost never need archival-grade PDF/A — a normal PDF is fine. Treat PDF/A as a specific compliance requirement to check for, not a default to aim for.

How to tell if a file is PDF/A

Most full-featured PDF readers show a document's conformance level somewhere in the file properties or a 'standards' panel, often labeled something like PDF/A-1b or PDF/A-2b. If you did not create the file yourself and a court or archive is asking for PDF/A, check that panel rather than assuming a regular export already qualifies — it usually does not.

Dedicated online and desktop validators exist specifically to check PDF/A conformance and will flag exactly which requirement a file fails, which is far more useful than guessing.

The trap: editing a PDF/A file can silently break it

This is the part people get burned by. Running a PDF/A file through almost any general-purpose PDF tool — compressing it, merging it with a non-PDF/A file, adding a password, even some watermarking operations — can strip the properties that made it PDF/A-compliant in the first place, and hand you back a file that opens fine today but no longer meets the standard.

That is true of Filemynt's tools as well, and we would rather say so directly: Filemynt does not produce or validate PDF/A output. If a court or archive specifically requires PDF/A, do your general editing, merging, and cleanup first on a non-PDF/A working copy, and perform the PDF/A conversion as the very last step, using software built for that conversion — then do not run the resulting file through any further tools before you submit it.

A safe order of operations

Structure the document first: merge exhibits, remove junk pages, fix orientation, add page numbers. Do your privacy pass — strip metadata, add a password only if the destination actually accepts encrypted PDF/A (many archival contexts do not, since encryption itself can violate the standard). Only after all of that is finished, convert to PDF/A with dedicated software and validate the result before you file or archive it.

If you are also fighting a court size limit, read that separately — compressing after PDF/A conversion is exactly the kind of step that can invalidate compliance, so resolve size constraints beforehand on the working copy.

What Filemynt is honestly good for here

Everything upstream of the PDF/A conversion: assembling the packet, removing pages that should not be filed, fixing rotation, adding page numbers for citation, and cleaning stray author metadata off a working draft before it becomes an official record. Studio keeps that whole preparation phase on one upload.

What we do not do is generate, validate, or guarantee PDF/A conformance. If that certification is a hard requirement for your filing, treat it as its own dedicated step handled by dedicated software, not as something a general compression or merge tool happens to preserve.

A quick gut check before you file

Does the destination explicitly say PDF/A? If not, a normal PDF is almost certainly fine. Does it say PDF/A? Prepare everything else first, convert last, validate the output, and do not touch it again with a general-purpose tool afterward.