Validate and convert PDFs to ISO 19005 archival standards

The archival problem

Why PDF/A exists when "PDF" already does

A regular PDF can have external dependencies. Fonts can be referenced by name without being embedded in the file — if the viewer in 2076 doesn't have that font installed, the rendering substitutes something approximate and the document subtly changes. Color spaces can be assumed without being specified — the viewer's defaults drift over decades and the colors no longer match the original print. Encryption can depend on a working certificate authority — if the CA is gone in 2076, the document is unrecoverable.

PDF/A (ISO 19005) is a constrained subset of PDF that forbids these dependencies. Every font must be fully embedded as a subset. Every color space must be specified with an embedded ICC profile. No encryption, no external references, no JavaScript that could behave unpredictably across software versions. The result is a file that will render the same way decades from now, on any conformant reader, regardless of what fonts or color profiles happen to be installed on that future system.

Government archives, legal records, healthcare records, scientific datasets, and accounting books that must be preserved for legally-mandated retention periods are required to be PDF/A. Regular PDF is a snapshot dependent on its environment; PDF/A is an archival document.

The three standards

PDF/A-1, PDF/A-2, PDF/A-3 — what changed and why it matters

Three generations of the PDF/A standard exist, each adding features the prior couldn't accommodate. All three define a Level B (basic) and Level A (accessibility) conformance — PDF Batch Editor targets Level B, the universal archival baseline. Level A adds tagged-document accessibility requirements that most PDF source tools don't generate cleanly, so it's typically a separate workflow.

PDF/A-1b   ISO 19005-1   Based on PDF 1.4. Strictest constraints.
                          NO transparency, NO JPEG2000, NO layers, NO embedded files.
                          Use when: 1b is explicitly required (some legacy archives).

PDF/A-2b   ISO 19005-2   Based on PDF 1.7. The modern default.
                          Adds: transparency, JPEG2000, optional layers, OpenType fonts.
                          Use when: nothing in particular forces a different choice.

PDF/A-3b   ISO 19005-3   Based on PDF 1.7. PDF/A-2 plus arbitrary attachments.
                          Allows embedding source files (XML, XLS, etc.) alongside
                          the rendered document.
                          Use when: archive must preserve both rendering and source data.

Pick PDF/A-2b unless you have a specific external requirement pointing at 1b (a legacy archival mandate, an old retention policy that hasn't been updated) or 3b (a workflow that needs the source-data attachment, like e-invoicing or research datasets). 2b is the right default in 2026.

Conformance area 1

Font embedding requirements

Every font used in a PDF/A document must be fully embedded as a subset. The "subset" is important — PDF/A doesn't require shipping the entire font glyph table, just the glyphs the document actually uses (subsetting is a space optimization that's compatible with PDF/A). The "fully embedded" part is the constraint: a font referenced by name without the corresponding glyph data is a violation, no matter how common or freely-available the font is.

The most common font violation in legacy PDFs is "Arial referenced but not embedded" — the source tool assumed every reader would have Arial installed. PDF Batch Editor's auto-fix detects unembedded font references, locates the font on the system (or an equivalent fallback), and embeds a subset containing only the glyphs the document references. Fonts that can't be located on the running system are flagged in the report for manual attention.

Conformance area 2

Color profiles and the output intent

Every PDF/A document must declare an output intent — an embedded ICC color profile that specifies the color space the document was authored against. Without it, color rendering depends on the viewer's defaults, which drift over decades and across software. With it, the file carries everything a future viewer needs to reproduce the original colors: the profile, the rendering intent, the explicit declaration of "this is the color world this document lives in".

Auto-fix adds a missing output intent using sRGB by default — the universal screen-display profile, right for any document that will be primarily viewed on screen. CMYK profiles (e.g. U.S. Web Coated SWOP) are appropriate for print-bound archives where the document originated in a print-color workflow. Beyond the output intent, individual color spaces used in the document content are checked: device-dependent color spaces (DeviceRGB, DeviceCMYK) without a defined output intent are violations and are remapped to ICC-based equivalents.

The validation report

Per-rule pass/fail with audit-evidence export

Validation produces a structured report for each file:

File: annual-report-2025.pdf
Target: PDF/A-2b
Status: 4 violations

Rule 6.2.2     FAIL  Font 'Arial' referenced but not embedded (page 12)
Rule 6.2.3.4   FAIL  Color space 'DeviceRGB' without output intent
Rule 6.7.2     FAIL  Required XMP metadata missing
Rule 6.6.4     FAIL  Encryption present (forbidden in PDF/A)

Auto-fix:      Will fix rules 6.2.2, 6.2.3.4, 6.7.2 (3 of 4)
               Manual review needed: rule 6.6.4 (decrypt before conversion)

Each rule code maps to a specific provision of the ISO 19005 standard. Auto-fixable violations are marked, manual-review violations are listed with the reason (e.g. "encryption present" requires you to decrypt the file with the Security module before conversion). After conversion, re-running validation against the output produces a clean pass report — that report is the auditable evidence that the document now meets the standard.