What is PDF/A and why validate against it?

PDF/A (ISO 19005) is an archival profile of PDF designed so a document can be reliably opened and reproduced decades from now. It enforces self-containment and removes anything that might not render later: fonts must be embedded, external dependencies and encryption are disallowed, multimedia and JavaScript are prohibited, colour must be device-independent, and the file must declare its conformance in metadata. Validating means checking that a file actually meets all of these rules — because a file can claim to be PDF/A, or look fine today, while failing requirements that matter for long-term preservation. For archives, records, legal, and regulatory storage, validation is how you trust that a document will still be usable in the future.

What are the PDF/A conformance levels?

PDF/A has versions (PDF/A-1, A-2, A-3, A-4) and, within them, conformance levels — most commonly "b" (basic) and "a" (accessible). Level "b" guarantees the visual appearance is preserved (the document will look the same in future). Level "a" additionally requires the document to be tagged and structured for accessibility and text extraction, a higher bar. Newer versions add capabilities (A-2 allows more, A-3 allows embedded source files). When validating, you check against a specific version and level, because "is this PDF/A?" only has a precise answer relative to a target like "PDF/A-2b." Choose the level your archive or regulator requires.

How do I validate a PDF's PDF/A compliance?

Run it through a PDF/A validator, which checks the file against every rule of the target version/level and produces a conformance report — pass, or a list of specific violations (e.g., "font X not embedded," "transparency present," "missing XMP metadata"). First detect what PDF/A version the file claims (if any), then validate against the level you need. A clean validation report is your evidence the file conforms; a report with violations tells you exactly what to fix. Do not rely on "it was saved as PDF/A" — saving and conforming are different, and validation is what confirms the difference.

What are the most common compliance failures?

Non-embedded fonts are the most frequent — a font referenced but not included, which breaks the "renders without external resources" guarantee. Live transparency is another (older PDF/A versions disallow it). Others: encryption (not allowed), prohibited content like embedded multimedia or JavaScript, missing or incorrect XMP metadata declaring conformance, device-dependent colour without a colour profile, and (for level "a") missing tags. Most are fixable: embed the fonts, flatten transparency, remove encryption and prohibited content, add the required metadata, and tag the document if you need level "a." A validator pinpoints which apply to your file.

How do I fix a file that fails validation?

Address the violations the report lists, then re-validate. The reliable path is to convert the document to PDF/A with a proper converter, which handles most requirements at once — embedding fonts, flattening transparency, removing disallowed content, and writing the conformance metadata — and then validate the result to confirm. For specific failures you can also fix targeted issues (embed a missing font, strip encryption) and re-check. Always re-validate after fixing, because fixing one violation can occasionally surface another, and only a clean report confirms compliance. Treat it as fix-then-revalidate until the report passes.

Does PDF/A guarantee my document is accessible?

Only at conformance level "a." Level "b" guarantees visual reproduction — the document will look the same in future — but does not require the tagging that makes it accessible to screen readers. Level "a" adds those accessibility and structure requirements. So if accessibility matters (which it often does for institutional archives), target a PDF/A-?a level and validate against it, and follow proper accessibility practices. Do not assume "it's PDF/A" means "it's accessible" — check the level. For a fully accessible archival document you want both PDF/A-a conformance and the accessibility work that underlies it.

Is it safe to validate confidential documents online?

Archives often contain sensitive records, so prefer a tool that processes files locally. ScoutMyTool validates PDF/A compliance, detects the PDF/A version, and converts to PDF/A entirely in your browser tab, so the document never leaves your machine. For anything confidential, confirm the tool does not upload before using it.

6 min read

How to validate PDF/A compliance for archival

By ScoutMyTool Editorial Team · Last updated: 2026-05-22

“We saved it as PDF/A” and “it is valid PDF/A” are not the same statement, and an archive that confuses them can discover years later that documents it trusted to last do not actually conform. PDF/A is the archival standard that makes a PDF reliably reproducible for decades — but only if the file truly meets its rules, which is what validation confirms. This guide explains what PDF/A requires, the conformance versions and levels, how to validate a file and read the conformance report, the common failures (non-embedded fonts, transparency, metadata), and how to fix a non-compliant file and re-validate until it passes.

What PDF/A requires

Requirement	Why
All fonts embedded	Renders identically without external fonts
No external dependencies	Self-contained for the long term
No encryption	Must remain openable indefinitely
No prohibited multimedia/JS	No content that may not render later
Device-independent colour	Colour reproducible across devices
XMP metadata + standard ID	Declares its conformance
Tagged (for PDF/A-a levels)	Accessibility/structure where required

Step by step — validate and conform

Know your target. Determine the PDF/A version and level your archive or regulator requires (e.g., PDF/A-2b, or A-2a if accessibility is needed).
Detect what the file claims. Check whether the PDF already declares a PDF/A version with PDF/A Version Detector.
Validate against the target. Run PDF/A Compliance Validator and read the report — pass, or a specific list of violations.
Fix the violations. Common ones: embed fonts (verify with Font Embedding Check), flatten transparency, remove encryption and prohibited content, add metadata — see PDF compatibility.
Convert if it is easier. A proper conversion handles most requirements at once — use PDF/A Converter (see PDF/A conversion).
Target level “a” if accessibility is required. Tag the document (see screen-reader accessibility) for the accessible conformance level.
Re-validate until clean. After fixing, validate again — fixing one issue can surface another; only a clean report confirms compliance.

PDF/A conversion: making a file conform.
PDF compatibility: fonts, transparency, standards.
Embedding fonts: the top compliance fix.
Screen-reader accessibility: for PDF/A level "a".
Clinical research docs: a regulated archival use case.
PDF/A Compliance Validator: check conformance in your browser.
All ScoutMyTool PDF tools: the full toolkit.

FAQ

What is PDF/A and why validate against it?: PDF/A (ISO 19005) is an archival profile of PDF designed so a document can be reliably opened and reproduced decades from now. It enforces self-containment and removes anything that might not render later: fonts must be embedded, external dependencies and encryption are disallowed, multimedia and JavaScript are prohibited, colour must be device-independent, and the file must declare its conformance in metadata. Validating means checking that a file actually meets all of these rules — because a file can claim to be PDF/A, or look fine today, while failing requirements that matter for long-term preservation. For archives, records, legal, and regulatory storage, validation is how you trust that a document will still be usable in the future.
What are the PDF/A conformance levels?: PDF/A has versions (PDF/A-1, A-2, A-3, A-4) and, within them, conformance levels — most commonly "b" (basic) and "a" (accessible). Level "b" guarantees the visual appearance is preserved (the document will look the same in future). Level "a" additionally requires the document to be tagged and structured for accessibility and text extraction, a higher bar. Newer versions add capabilities (A-2 allows more, A-3 allows embedded source files). When validating, you check against a specific version and level, because "is this PDF/A?" only has a precise answer relative to a target like "PDF/A-2b." Choose the level your archive or regulator requires.
How do I validate a PDF's PDF/A compliance?: Run it through a PDF/A validator, which checks the file against every rule of the target version/level and produces a conformance report — pass, or a list of specific violations (e.g., "font X not embedded," "transparency present," "missing XMP metadata"). First detect what PDF/A version the file claims (if any), then validate against the level you need. A clean validation report is your evidence the file conforms; a report with violations tells you exactly what to fix. Do not rely on "it was saved as PDF/A" — saving and conforming are different, and validation is what confirms the difference.
What are the most common compliance failures?: Non-embedded fonts are the most frequent — a font referenced but not included, which breaks the "renders without external resources" guarantee. Live transparency is another (older PDF/A versions disallow it). Others: encryption (not allowed), prohibited content like embedded multimedia or JavaScript, missing or incorrect XMP metadata declaring conformance, device-dependent colour without a colour profile, and (for level "a") missing tags. Most are fixable: embed the fonts, flatten transparency, remove encryption and prohibited content, add the required metadata, and tag the document if you need level "a." A validator pinpoints which apply to your file.
How do I fix a file that fails validation?: Address the violations the report lists, then re-validate. The reliable path is to convert the document to PDF/A with a proper converter, which handles most requirements at once — embedding fonts, flattening transparency, removing disallowed content, and writing the conformance metadata — and then validate the result to confirm. For specific failures you can also fix targeted issues (embed a missing font, strip encryption) and re-check. Always re-validate after fixing, because fixing one violation can occasionally surface another, and only a clean report confirms compliance. Treat it as fix-then-revalidate until the report passes.
Does PDF/A guarantee my document is accessible?: Only at conformance level "a." Level "b" guarantees visual reproduction — the document will look the same in future — but does not require the tagging that makes it accessible to screen readers. Level "a" adds those accessibility and structure requirements. So if accessibility matters (which it often does for institutional archives), target a PDF/A-?a level and validate against it, and follow proper accessibility practices. Do not assume "it's PDF/A" means "it's accessible" — check the level. For a fully accessible archival document you want both PDF/A-a conformance and the accessibility work that underlies it.
Is it safe to validate confidential documents online?: Archives often contain sensitive records, so prefer a tool that processes files locally. ScoutMyTool validates PDF/A compliance, detects the PDF/A version, and converts to PDF/A entirely in your browser tab, so the document never leaves your machine. For anything confidential, confirm the tool does not upload before using it.

Citations

Wikipedia — “PDF/A” (ISO 19005), the archival standard, its versions, and conformance levels. en.wikipedia.org/wiki/PDF/A
Wikipedia — “Digital preservation,” why archival formats and validation matter. en.wikipedia.org/wiki/Digital_preservation
Wikipedia — “PDF” (ISO 32000), the base format PDF/A profiles. en.wikipedia.org/wiki/PDF

Trust your archive — validate it

Detect, validate, and convert PDF/A with ScoutMyTool’s in-browser tools — your records never leave your machine, and you ship documents that conform, not just claim to.

Open PDF/A Validator →