Archival and PDF/A

SpecSpec: ISO 19005-4:2020, PDF/A-4ISO 19005-4:2020 PDF/A-4SpecSpec: ISO 19005-2, PDF/A-2ISO 19005-2 PDF/A-2

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 permanenceEmbed every font, use device-independent colour or an output intent, and avoid features the chosen PDF/A part forbids.
2. Enable the PDF/A modeOpt in explicitly to the target conformance level. The mode now guards the document against incompatible operations.
3. Validate independentlyRun a conformance checker. A passing report — not the producing library — is the evidence the archive needs.
4. Preserve with procedureStore 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

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.

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.

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.