Back to blog
GuidesApril 20, 20265 min readKonvrt Team

PDF/A for Long-Term Archival: 2026 Conversion Guide

The differences between PDF/A-1, -2, and -3, what counts as compliant, and how to produce archival PDFs for legal and government submissions.

PDF/A for Long-Term Archival: 2026 Conversion Guide

PDF/A is not a different file format from PDF. It is a constrained subset of PDF defined by ISO 19005 that guarantees a document will render the same way decades from now. Fonts are embedded. Color spaces are declared. JavaScript, external links, encryption, and audio are all forbidden. You end up with a file that an archivist's great-grandchild can still open.

If you are submitting to a court, a national archive, or a regulator, PDF/A is usually mandatory. The federal courts in the United States require PDF/A for all CM/ECF filings since 2021. The UK National Archives mandate PDF/A-2b or PDF/A-3b for transfer. The European Commission's eIDAS framework references PDF/A-2 for long-term signature preservation.

PDF/A-1, -2, -3: the practical differences

The three conformance levels most people will encounter:

Version Based on Year Notable allowances
PDF/A-1 PDF 1.4 ISO 19005-1:2005 No transparency, no layers, no JPEG2000
PDF/A-2 PDF 1.7 ISO 19005-2:2011 Transparency, layers, JPEG2000, PDF/A files embedded
PDF/A-3 PDF 1.7 ISO 19005-3:2012 Any file type may be embedded (XML, CSV, source docs)

Each version has conformance sub-levels: b (basic visual fidelity), u (Unicode text extraction), and for PDF/A-2 and -3 also a (accessibility, full structure and tagging).

Most legal filings accept PDF/A-1b or PDF/A-2b. Government tenders that want the original source attached (a filled XML form, a signed XBRL financial statement) require PDF/A-3. Accessibility mandates like the EU Web Accessibility Directive pull you toward the a level.

If you do not know which version to pick, PDF/A-2b is the safe default. It handles modern PDF features that PDF/A-1 chokes on, and conformance is straightforward.

What breaks during conversion

The common failure modes when converting a normal PDF to PDF/A:

  • Unembedded fonts. Any font the document uses must be embedded. Standard PDF viewers will substitute Helvetica if a font is missing; PDF/A forbids this. Scan the source with a tool that reports font status before you convert.
  • Undeclared color spaces. Every color must reference either a calibrated color space or an output intent. Setting a document-level ICC profile (sRGB IEC61966-2.1 for screen, FOGRA39 for European print) fixes this for most files.
  • Transparency. Allowed in PDF/A-2 and -3, forbidden in PDF/A-1. If you need PDF/A-1 compliance, transparent objects get flattened, which can change how layered graphics look.
  • JavaScript and forms. Any interactive JavaScript must be stripped. AcroForm fields are allowed, but the validation logic attached to them is not.
  • External references. Hyperlinks to external URLs are technically allowed (as annotations), but anything that loads external content (remote images, streamed video, external CSS) is out.

A PDF with all five problems is not unusual. A marketing brochure exported from InDesign typically has transparency, web-optimized fonts subset incompletely, and links to campaign landing pages. Running it through a compliance check first saves a round of rejection later.

Embedded fonts, specifically

Fonts are the thing that catches most people. Three common mistakes:

  1. Subsetted fonts without the full glyph table. A PDF can embed only the glyphs actually used. This is allowed in PDF/A as long as the CIDSet or CIDToGIDMap is present and correct. Some older export pipelines omit the map and fail validation even though the glyphs are physically in the file.
  2. Type 3 fonts. Bitmap fonts generated by some scanning software are not archival-safe. Re-OCR the document or re-render with a real font.
  3. Licensing flags. A font that has its embedding bit set to "no embedding" (some foundry fonts) legally cannot go in a PDF/A. You have to substitute a licensed alternative.

A validator like veraPDF (free, open-source, run by the PDF Association) will catch all three. Run it on the output before you submit.

For US federal court CM/ECF: PDF/A-1b or PDF/A-2b, under 50 MB per document, no password protection. Each document gets an OCR text layer if it started as a scan.

For EU public procurement (TED): PDF/A-2b minimum, PDF/A-2a preferred for bids that include structured data. Signatures must be PAdES-LTV.

For UK National Archives transfer: PDF/A-2b or -3b, documented in the Digital Records Infrastructure guidance.

If your documents contain sensitive metadata (authors, revision history, comments), strip it before you convert. PDF/A preserves XMP metadata by design, and a redacted-looking document with a 400-revision edit history is a frequent accidental disclosure. A local converter like the one at /convert runs the conversion in your browser, so the pre-compliance copy never leaves your machine. For ingesting a case folder of a few hundred files at once, /batch handles the full set without per-file reuploads.

A minimal correctness checklist

Before submitting a PDF/A anywhere, verify:

  • Fonts embedded (full or subset with CIDSet)
  • Output intent present, ICC profile declared
  • No JavaScript, no encryption, no audio/video
  • Metadata in XMP, synchronized with DocInfo
  • Validates clean in veraPDF against the target conformance level

If all five pass, the file will survive the rendering engines of 2050 just as cleanly as today's.

Built for fast file workflows

Convert, optimize, and ship files without sending them away first.

Konvrt keeps the experience simple: local-first processing when possible, clear pricing, strong privacy defaults, and focused tools for repetitive file work.

Local-first

Files stay on your device for supported browser workflows.

Fast answers

Use FAQ, docs, and contact paths without hunting around the site.

Clear upgrades

Move from free workflows to paid access without confusing plan language.