Check a PDF

Most people arrive at this problem holding a file rather than a specification. A customer has asked whether your documents are accessible, or a deadline has appeared in a procurement questionnaire, and the practical question is whether the PDF your system already produces passes.

This answers that. It runs veraPDF — the reference implementation the standards bodies maintain, and the tool an auditor is likely to run — and reports the verdict along with what the file actually is. No account, no card.

What the answer means

A verdict on its own is not much use, so the report also says what the file is. Three things are worth knowing before you read a failure list.

Tagged is not conformant. Almost every PDF tool can emit a structure tree. Tagging is a necessary condition of PDF/UA-1 and not a sufficient one, and most of the gap between the two is in table headers. That distinction has its own page.

A claim in the metadata is not a verdict. A file can declare itself PDF/A-3b in its XMP and fail validation against it. The claim is what the producer intended; the verdict is what the file is.

An archival level is not an accessibility level. PDF/A comes in conformance levels, and only Level A requires tagging. If the report says your file claims PDF/A-3b, it is archival and machine-readable and a screen reader still cannot read it.

If it is an e-invoice

A Factur-X or ZUGFeRD invoice is a PDF/A-3 container carrying an EN 16931 XML payload. The check looks for that payload and says so, because the combination is the common case and nobody warns about it: the e-invoicing specifications constrain the attachment and leave the conformance level open, so implementations reach for Level B, and Level B is not tagged. The full version of that argument is here.