PDF/A Validation Guide: What a Pass or Failure Really Means

PDF/A validation is not PDF/A conversion

A useful PDF/A validation guide starts with a strict distinction: validation checks an existing file, while conversion rewrites a file in an attempt to meet a chosen profile. A validator applies formalised rules and reports which requirements pass or fail. It does not silently make the document archival, repair missing fonts or decide whether the content belongs in your records system.

BuiltForAnything provides a Validate PDF/A tool and a separate PDF to PDF/A conversion tool. The validation handler reports veraPDF conformance against the checked PDF/A profile and fails closed when validation is unavailable or ambiguous. It does not convert or repair the PDF and is not an archival-suitability, legal-admissibility, accessibility or visual-fidelity guarantee. Conversion instead rewrites a copy in an attempt to meet the selected profile; preserve the source, validate the conversion result and compare it visually because a conforming container is not useful if important content or behaviour was lost.

Validation also differs from opening a file without an error. A viewer is designed to display many PDFs, including damaged files it can repair on the fly. PDF/A applies additional constraints intended to improve long-term reproducibility. A document can look normal in today's viewer and still fail because of fonts, colour spaces, metadata, encryption or prohibited actions.

Choose the PDF/A profile before you test

PDF/A is a family, not one switch. PDF/A-1 is based on PDF 1.4. PDF/A-2 and PDF/A-3 are based on PDF 1.7, and PDF/A-3 permits embedded files of other formats. PDF/A-4 is based on PDF 2.0. Within earlier parts, conformance levels place different demands on visual reproduction, Unicode mapping and logical structure.

Do not choose the newest or strictest label by instinct. Start with the receiving archive, regulator, court, client or records policy. A repository may require a specific part and level, forbid attachments even where a profile allows them, or require separate source files. If no requirement exists, document why the selected profile fits the content and preservation plan.

A validator may infer a profile from the file's conformance declaration or let you select one explicitly. Record the actual profile used. Testing a file against PDF/A-2b and saying only 'PDF/A passed' removes information that another reviewer needs to reproduce the result.

• Match an explicit recipient or repository specification first.
• Treat PDF/A-3 attachments as a records-policy decision, not automatic permission to embed anything.
• Do not equate PDF/A level A with PDF/UA accessibility conformance.
• Record the validator, version, profile, time and exact artifact tested.

How to read a PDF/A validation report

Begin with the result, selected profile and number of failed rules. Then move from rule identifiers to affected objects. A good report names the applicable requirement, describes the test condition and identifies occurrences. One underlying defect can produce many failures, so a large count does not necessarily mean many unrelated problems.

Group findings by likely remediation: fonts and glyph mapping, colour and output intents, metadata, actions and interactive content, embedded files, transparency or structural information. Keep the original report before attempting a fix. After conversion or repair, validate the new artifact and compare reports rather than overwriting the evidence from the first run.

A validator can only test what its model and profile formalise. The veraPDF documentation distinguishes formal validation rules and, for accessibility, machine-verifiable checks from human checkpoints. The same caution applies generally: automation cannot decide whether a scan is readable, a page is missing, a title is accurate or a repository's local policy is satisfied.

1. 1

   Identify

   Confirm the exact file, claimed conformance and profile actually tested.

2. 2

   Group

   Cluster repeated failures by rule and affected PDF feature before choosing a remediation.

3. 3

   Retest

   Validate the rewritten output as a new artifact and retain both reports when the workflow requires evidence.

What a PDF/A pass does and does not prove

A pass supports a narrow statement: the tested bytes satisfied the validator's machine-checkable rules for the selected profile. It does not prove that the file shown to the reviewer is the same file later submitted unless identity is preserved. Store the report with an unambiguous filename or hash and avoid modifying the PDF after validation.

A pass does not prove that every page matches the source, text is correct, images are sharp, links are appropriate, reading order is usable or confidential material is absent. It does not make the file a complete archival package. Format conformance is one part of preservation alongside provenance, fixity, metadata, storage, access and migration planning.

It also does not guarantee acceptance. A receiving system can impose page-size, file-size, encryption, signature, naming or content rules outside PDF/A. Validate the profile, then test the actual submission requirements using the same output artifact.

Remediate failures without losing the record

Never repair the only copy. Conversion may embed substitute fonts, flatten transparency, rewrite colour, remove encryption, discard prohibited actions or change metadata. Those changes can be appropriate for an access or preservation copy, but they may also alter appearance or invalidate certificate signatures. Keep the received file under the applicable retention rules.

Prioritise the root cause instead of chasing individual counts. If fonts are missing, return to the source application where possible and export with the correct settings. If the document is a scan, preserve the image master if policy requires it. If an existing signature matters, decide whether an unsigned archival rendition and the signed original must both be kept.

After remediation, run validation again, open the output in a separate viewer and compare critical pages. For sensitive documents, follow the private PDF workflow checklist so validation evidence is tied to source preservation, output review and controlled delivery.

• Keep source, remediated output and validation evidence distinct.
• Recheck fonts, small text, transparency, forms, attachments and signatures affected by rewriting.
• Document limitations that remain even when the selected profile passes.
• Have the receiving repository confirm any policy-specific uncertainty.

The five-minute PDF/A validation checklist

Before delivery, confirm the requirement and selected profile, preserve the source, validate the intended output, save the full report, and perform a visual comparison. Open the exact file that will be transferred. If any system adds a cover page, stamp or signature after validation, the resulting file is different and should be tested again.

Start with a non-sensitive representative fixture and inspect the conversion output rather than treating the completion message as archival approval. The most defensible result is not simply 'pass'; it is a reproducible record of what was tested, against which profile, with which result and which human checks followed.

1. 1

   Requirement

   Confirm the requested PDF/A part and level plus any repository-specific rules.

2. 2

   Identity

   Preserve the source and identify the exact output to be tested.

3. 3

   Validation

   Run the selected profile and retain the detailed machine-readable or human-readable report.

4. 4

   Review

   Compare critical pages, text, fonts, attachments and signatures against the source and purpose.

5. 5

   Transfer

   Submit the validated bytes without another edit, or validate again after the final transformation.