Archival and PDF/A

Spec Spec: ISO 19005-4:2020, PDF/A-4 ISO 19005-4:2020 PDF/A-4 Spec Spec: ISO 19005-2, PDF/A-2 ISO 19005-2 PDF/A-2 Evidence § Standard-backed Evidence: Standard-backed

At a glance

PDF/A is the format you reach for when a document has to be readable and faithful decades from now, on software that does not exist yet. This page explains what that guarantee actually covers, how NextPDF produces a conforming file, and the part that surprises teams: producing PDF/A and proving a file is PDF/A are two different jobs. The second one is still yours.

Why this matters

Archival obligations are unforgiving in a quiet way. The file looks fine today, so it gets filed. The failure — a non-embedded font, a device-dependent colour, an encrypted trailer — surfaces years later, when the original environment is gone and nobody can reconstruct what the document was supposed to look like. By then the cost is not a re-render; it is a record you can no longer trust.

PDF/A exists precisely to remove that class of failure. But “we used a PDF/A library” is not the same as “this file conforms”. Conflating the two is how archives accumulate documents that only appear preserved.

The short version

• PDF/A’s purpose is faithful, self-contained, device-independent reproduction over time — it preserves a document’s static visual appearance independent of the tools that made it (ISO 19005-2 Introduction).
• That requires concrete constraints: all fonts embedded, device-independent colour (directly or via an output intent; ISO 19005-4 §6.2.4.1), and no encryption in the trailer.
• NextPDF produces PDF/A through an explicit, opt-in mode that refuses incompatible operations rather than emitting a file that silently is not conformant.
• Conformance is determined by a checking tool, not asserted by the producer. Even the standard’s own success depends on the surrounding archival environment and procedures (ISO 19005-4 Introduction). Validating the output is a step you still owe.

How NextPDF approaches it

NextPDF treats PDF/A as a mode the document is in, not a post-processing filter. The mode is opt-in. Once it is on, it actively guards the document against operations that would break conformance. The design principle is fail-fast. It is better to refuse an encrypted PDF/A request loudly than to hand back a file that looks archival and is not.

The scenario has four stages. The third is the one teams skip.

1. Compose for permanence Embed every font, use device-independent colour or an output intent, and avoid features the chosen PDF/A part forbids.
2. Enable the PDF/A mode Opt in explicitly to the target conformance level. The mode now guards the document against incompatible operations.
3. Validate independently Run a conformance checker. A passing report — not the producing library — is the evidence the archive needs.
4. Preserve with procedure Store under records-management policy. The standard itself notes archival success depends on the environment, not the file alone.

The archival scenario end to end: the engine produces a conforming candidate and refuses conformance-breaking operations; an independent validator delivers the verdict that actually matters for an archive.

The opt-in is a real guard, not a flag. When the PDF/A mode is enabled and an incompatible operation is attempted — turning on AES-GCM or the standard encryption handler — the engine raises a typed incompatibility error. The guard works in both orders: enable PDF/A then request encryption, or request encryption then enable PDF/A. Either way, the result is a clear refusal. ISO 19005 forbids the Encrypt key in the trailer of a conforming file, and the engine treats that as binding rather than advisory.

The mode also keeps its own state honest. Enabling PDF/A for a specific part (for example a PDF/A-3 byte-faithful level versus PDF/A-4) sets the document’s conformance discriminant to match. Writer-side gates that depend on the part then see the right value rather than a stale default. This is the kind of internal consistency that decides whether a validator passes the file.

Human-factors note: Human-factors note

The most important sentence on this page is not about the engine. PDF/A conformance is a property of the final file plus a validator, not a property of the software that produced it. ISO 19005-4 is explicit that successful archival also depends on the organization’s retention requirements, records-management procedures, and any additional conditions needed for persistence over time. NextPDF gives you a conforming candidate and refuses to break it. The verdict, and the archive’s durability, come from the validator and the process around it.

What the evidence says

This page is standard-backed throughout. Evidence § Standard-backed Evidence: Standard-backed

The purpose is fixed by the standard. Spec Spec: ISO 19005-2 ISO 19005-2 states PDF/A’s primary purpose is a mechanism for representing electronic documents so their static visual appearance is preserved over time, independent of the tools and systems used. The constraints follow from that: Spec Spec: ISO 19005-4:2020, §6.2.4.1 ISO 19005-4:2020 §6.2.4.1 requires colour to be specified device-independently, directly or through the PDF/A output intent. The font requirement is reinforced by the base format — Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 notes the most predictable, dependable rendering occurs when all fonts are embedded, the exact property an archive cannot do without.

The boundary is also in the standard, not only an editorial caution. Spec Spec: ISO 19005-4:2020 ISO 19005-4:2020 states in its Introduction that successful implementation for archival purposes depends on the organization’s archival environment, records-management policies, and additional persistence conditions. Conformance is judged against the standard’s normative requirements by a checking tool — not declared by the producer.

The engine behaviour is code-backed: Evidence { } Code-backed Evidence: Code-backed Document::enablePdfA() is an explicit opt-in that raises a typed incompatibility error when encryption and PDF/A are combined in either order, and keeps the document’s conformance discriminant in lock-step with the selected part.

Practical example

The code below shows the guard behaviour at the seam. The PDF/A mode itself is a Premium-tier capability. The conformance check is a separate, independent step.

<?php

declare(strict_types=1);

use NextPDF\Contracts\PdfDocumentInterface;
use NextPDF\Security\Exception\IncompatiblePdfAModeException;

/**
 * Produce an archival candidate, then prove it independently.
 *
 * The engine refuses conformance-breaking combinations; it does NOT
 * certify the result. A validator does that.
 *
 * @param PdfDocumentInterface $doc       A document with all fonts embedded
 * @param object               $pdfaLevel The target PDF/A version (Premium enum)
 *
 * @return string The archival candidate's bytes — not yet a verified PDF/A
 */
function buildArchivalCandidate(
    PdfDocumentInterface $doc,
    object $pdfaLevel,
): string {
    try {
        // Opt in explicitly. From here the mode guards the document.
        $doc->enablePdfA($pdfaLevel);
    } catch (IncompatiblePdfAModeException $e) {
        // e.g. encryption was already requested — refused, not silently
        // downgraded into a non-conforming "archival" file.
        throw new \RuntimeException(
            'PDF/A and encryption are mutually exclusive for a conforming '
            . 'file; resolve before archiving.',
            previous: $e,
        );
    }

    $bytes = $doc->getPdfData();

    // The step teams skip: this is a CANDIDATE. Run an independent
    // conformance validator before treating it as a preserved record.
    return $bytes;
}

The comment on the return is the lesson. The function name says candidate on purpose. The engine produced something that should conform. Only a checker turns “should” into evidence.

Common misconception

One misconception fills archives with unpreserved documents: “the library says PDF/A, therefore the file is PDF/A.” It is not the library’s verdict to give. A producer can emit a file intended to conform and still miss a normative requirement. Conformance is determined against the standard by a validation tool. That determination is what an auditor or a future reader relies on. Treating the producing library’s intent as proof is the core error.

A second, subtler trap: assuming PDF/A alone preserves the document. The standard itself ties archival success to the surrounding environment and procedures. A conforming file in an undisciplined repository is still at risk. The format is necessary, not sufficient.

Limits and boundaries

• NextPDF produces a conforming candidate; it does not certify conformance. Run an independent validator. A passing report is the evidence, not the producing library.
• PDF/A conformance modes are a Premium-tier capability. Core emits plain PDF 2.0 and surfaces an actionable upgrade path. It does not provide PDF/A guarantees. See the boundary below.
• PDF/A and encryption are mutually exclusive for a conforming file. The engine refuses the combination in either order rather than degrading silently.
• The engine cannot embed fonts it is not given or fix device-dependent colour you supply. Composing for permanence — embedded fonts, device-independent colour — is an input responsibility.
• Archival durability depends on process, not the file alone. ISO 19005 makes organizational retention and records-management procedures part of successful preservation.
• This page is standard-backed and behaviour-level on the Premium surface. It asserts no certification and grants none.

PDF/A archival conformance — edition availability

Edition	Availability
Core	○ Core produces plain PDF 2.0 only. enablePdfA() raises an actionable upgrade error pointing at the commercial package. There is no Core-only PDF/A guarantee.
Pro	○ PDF/A conformance modes (including byte-faithful PDF/A-3 levels and PDF/A-4) are available, with the encryption-incompatibility guard.
Enterprise	○ Adds a structural PDF/A conformance policy and report (still a structure check, not a certification — final determination belongs to a validator and your compliance team).

Related docs

• Fonts: the hard part — why a font that looks right can still make a file non-conformant or unsearchable.
• Golden-file testing — how pinned reference output catches the byte drift that quietly breaks archival guarantees.
• Invoices and e-invoicing — the closest neighbour: a hybrid invoice carrier is itself a PDF/A file.

Glossary

• PDF/A — the ISO 19005 family: a constrained PDF profile for long-term preservation, designed to reproduce a document’s static appearance over time independent of the producing tools.
• Conformance level / part — the specific PDF/A variant (for example PDF/A-2, PDF/A-3, PDF/A-4 and its sub-levels); each constrains which PDF features may be used.
• Output intent — an embedded colour-characterization profile that lets device-dependent colour be interpreted device-independently.
• Device-independent colour — colour specified so it reproduces consistently regardless of the rendering device, a PDF/A requirement.
• Conformance checker / validator — independent software that judges a file against the standard’s normative requirements; the source of the conformance verdict.
• Archival candidate — a file produced intending to conform, before an independent validator has confirmed it actually does.