Archival (PDF/A)

PDF/A is an ISO standard (ISO 19005) for long-term document preservation. It ensures that a PDF is self-contained: all fonts are embedded, colors are device-independent, and no external dependencies exist. PDF/A is required in legal filings, government records, regulatory submissions, medical records, and any context where documents must remain readable decades from now. Forme produces PDF/A-2 at conformance levels 2b, 2u, and 2a, verified with veraPDF as a CI gate: every corpus document is rendered as PDF/A and PDF/UA-1 together and validated against both profiles on every commit.

Files produced before 0.16.0 are not valid PDF/A. Earlier versions embedded an invalid sRGB ICC profile, so pdfa output from 0.15.0 and below fails validation (verapdf -f 2b file.pdf reports FAIL). Re-render those documents with 0.16.0 or later — same input, same options — and they pass. PDF/A also requires embeddable fonts: register @formepdf/fonts-standard (or your own). If a font can’t be embedded, the render fails with a named error rather than emitting a file that falsely claims conformance.

Enabling PDF/A

Add the pdfa prop to your Document component with the desired conformance level:

<Document pdfa="2b" title="Contract Agreement" author="Legal Dept">
  <Page size="A4" margin={54}>
    <Text style={{ fontSize: 24, fontWeight: 700 }}>Service Agreement</Text>
    <Text style={{ fontSize: 10, lineHeight: 1.6 }}>
      This document is PDF/A-2b compliant for long-term archival.
    </Text>
  </Page>
</Document>

Supported Levels

Forme supports two PDF/A conformance levels:

Level	Standard	Description
`"2b"`	PDF/A-2b	Visual preservation. Guarantees the document looks the same when opened years later. The most common level for general archival.
`"2a"`	PDF/A-2a	Visual preservation + full tagged structure. Requires the same structure tree as PDF/UA (reading order, role map, alt text). Use when both archival and accessibility are required.

{/* Most common -- visual preservation */}
<Document pdfa="2b">...</Document>

{/* Tagged structure required (forces tagging, same as pdfUa) */}
<Document pdfa="2a">...</Document>

If you are unsure which level to use, start with "2b". It covers the majority of archival requirements and has the broadest acceptance.

PDF/A-3 (`3b`, `3u`, `3a`)

PDF/A-3 extends PDF/A-2 with permission for embedded file attachments (XML data, source spreadsheets, machine-readable invoices) — same rule set otherwise, same level semantics:

const pdf = await renderDocument(<Document pdfa="3b">...</Document>, {
  attachments: [{ name: 'data.xml', data: xmlBytes, mimeType: 'application/xml' }],
});

Attachments under PDF/A-2 are refused with a named error — part 2 permits only PDF/A attachments, which the engine cannot verify; the error tells you to use "3b". The main use case, Factur-X/ZUGFeRD e-invoice containers, has its own guide.

PDF/A-4 (`4`, `4f`) — the PDF 2.0 archival standard

ISO 19005-4:2020 is defined over PDF 2.0 (ISO 32000-2). Claiming it implies pdfVersion: "2.0" — the header, XMP-only document metadata (no trailer Info dictionary), and one consequence worth reading twice:

Every font must be embedded under PDF 2.0. ISO 32000-2 removes the special provision for the standard-14 fonts, so Forme’s non-embedded Helvetica/Times/Courier defaults hard-error under pdfa="4" (and under plain pdfVersion: "2.0"). Register @formepdf/fonts-standard or your own fonts — the same requirement the 1.7 PDF/A levels already carry, now triggered by the version itself.

PDF/A-4 is not an accessibility claim. Part 4 drops the a/b/u split entirely — there is no Level A, and no tagging requirement. Accessibility moved wholly to PDF/UA-2: compose pdfa="4" with pdfUa2 for a file that is archival AND accessible on PDF 2.0 (on PDF 1.7, the equivalent pair is pdfa="2a"/"3a" + pdfUa). “PDF/A-4 verified” alone says the file will open identically in thirty years; it says nothing about screen readers.

// Plain A-4 — no attachments permitted beyond other PDF/A files
const pdf = await renderDocument(<Document pdfa="4">...</Document>);

// A-4f — arbitrary embedded files, and AT LEAST ONE IS REQUIRED:
// an A-4f file with an empty EmbeddedFiles tree is itself
// non-conformant (ISO 19005-4 Annex A; veraPDF clause 6.9-t5), so
// Forme refuses a "4f" claim with nothing attached.
const pdf4f = await renderDocument(<Document pdfa="4f">...</Document>, {
  attachments: [{ name: 'data.csv', data: csvBytes, mimeType: 'text/csv' }],
});

Both levels are veraPDF-validated in CI over the same corpus as the 1.7 levels. The 1.7-based claims (pdfa 2x/3x, pdfUa) are contradictions under pdfVersion: "2.0" and error by name. The HTML path accepts pdf_a: "4"; "4f" there is refused until the HTML path grows an attachments option.

What Forme Handles

When pdfa is set, Forme automatically ensures the output conforms to the standard:

Font embedding — All fonts (including subsets) are fully embedded in the PDF. No external font references.
sRGB output intent — An sRGB ICC color profile is embedded as the document’s output intent, ensuring colors render consistently across devices.
XMP metadata — Document title, author, and conformance level are written as XMP metadata packets (required by PDF/A).
Document ID — A unique /ID array is written in the PDF trailer (required by PDF/A).
No encryption — PDF/A prohibits encryption. If you need to restrict access, use application-level controls instead of PDF encryption.
No JavaScript — PDF/A prohibits embedded JavaScript. Forme does not embed JavaScript in any case, so this is always satisfied.

Combining with PDF/UA

For documents that need both archival compliance and accessibility (common in government and healthcare), combine both props:

<Document pdfUa pdfa="2b" title="Accessible Archival Report" lang="en">
  <Page size="A4" margin={54}>
    <Text style={{ fontSize: 20, fontWeight: 700 }}>Annual Compliance Report</Text>
    <Image src="./chart.png" width={400} alt="Compliance metrics for fiscal year 2025" />
  </Page>
</Document>

This produces a PDF that satisfies both PDF/UA-1 and PDF/A-2b. See the Accessibility guide for PDF/UA details. Using pdfa="2a" also works here. PDF/A-2a requires the same tagged structure that PDF/UA demands, so the two standards align naturally.

Known Limitations

No encryption. PDF/A explicitly prohibits document encryption. Attempting to combine encryption with PDF/A will produce a non-conformant file.

Level Comparison

Capability	PDF/A-2b	PDF/A-2a
Visual preservation	Yes	Yes
Font embedding	Yes	Yes
sRGB output intent	Yes	Yes
XMP metadata	Yes	Yes
Tagged structure tree	No	Yes (required)
Form fields (AcroForm)	Yes	No
Combined with PDF/UA	Yes	Yes

Getting Started

Template Library

Reference

API Reference

Concepts

Enterprise

SDKs

Guides

Changelog

Archival (PDF/A)

Enabling PDF/A

Supported Levels

PDF/A-3 (`3b`, `3u`, `3a`)

PDF/A-4 (`4`, `4f`) — the PDF 2.0 archival standard

What Forme Handles

Combining with PDF/UA

Known Limitations

Level Comparison

​Enabling PDF/A

​Supported Levels

​PDF/A-3 (3b, 3u, 3a)

​PDF/A-4 (4, 4f) — the PDF 2.0 archival standard

​What Forme Handles

​Combining with PDF/UA

​Known Limitations

​Level Comparison

Enabling PDF/A

Supported Levels

PDF/A-3 (`3b`, `3u`, `3a`)

PDF/A-4 (`4`, `4f`) — the PDF 2.0 archival standard

What Forme Handles

Combining with PDF/UA

Known Limitations

Level Comparison