The program that decides whether a document complies

veraPDF is a free program that opens a document and says whether it really follows the archiving rule it claims to follow. It is published by the bodies that write that rule, so its answer comes from outside. This page says what it decides, how to run it on a file of your own, and the two uses made of it here.

Summary

Think of the test a car goes through every year. The garage that services it all year long is not the one that awards the certificate: somebody else looks at the car, with the published list in hand, and says yes or no. veraPDF is that somebody, for a document.

It is a program anybody may download and run, free of charge, and it comes from the two bodies that write the archiving rule itself: the Open Preservation Foundation and the PDF Association. The list it checks against is therefore the list, kept by the people who wrote it.

Here is why that matters the day you choose a supplier. A program grading its own files would measure them with the very understanding that produced them: read the rule one way, write the file that way, and call it correct. A check from outside is the one thing that catches a misreading, and it is what an archive, an auditor or a court has in mind when it asks for a document that complies.

Using it takes a minute. You download it, you point it at a file, and you name the rule the file is to be measured against. It answers with a plain pass or fail, and behind that answer it lists every rule it applied, each carrying the number of its article in the published text, so anything it turned down can be looked up word for word.

The team here uses it twice over. The first use decides what the engine does: veraPDF carries the rules it applies in writing, article by article, in files anybody can open. Those files are read before a rule goes into the engine, so what the engine insists on is what the published text asks for, read off the checker rather than remembered.

The second use is the plain one: what comes out goes in front of it. An invoice of three pages, laid on page templates as LibreOffice wrote them and carrying its data file inside it, is declared an archival document on 146 rules and 5 456 separate checks, every one of them satisfied. A document of the fourth part, carrying a hierarchy of its own parts and a link into one of them, passes on 109 rules out of 109. Both figures are read off veraPDF's own report, and both can be produced again on your own machine.

veraPDF covers the two families this engine is measured on: documents kept for the long term, and documents read aloud to somebody who cannot see the page. The printing family is decided another way, and the page on print-ready files says how, and what the engine guarantees there.

Technically

The call, the flavours it decides on, where its rule profiles live, and what a report holds.

Running it on a file of your own

The command-line build is a Java program with an installer of its own; unpacking it leaves an executable that takes one file and one flavour. The flavour is the exact rule the file is measured against, and naming it is what turns a vague question into a decision. The version the figures on this page were produced with is 1.30.2.

The answer arrives on one line: the verdict, the flavour and the path. Everything behind that line is available as a report — a machine-readable one naming every rule, the objects it was applied to and the message of each test, and a plain one for reading.

Asking for successes as well turns the report into the whole profile. A rule that ran and passed is then told apart from a rule that had nothing to look at, which is the difference between a check that happened and a check that was skipped.

verapdf --format text -f 3b invoice.pdf
verapdf --format mrr --success -f ua1 invoice.pdf > report.xml

The flavours it decides on

Fifteen flavours ship with it. The archival family holds 1a, 1b, 2a, 2b, 2u, 3a, 3b, 3u, 4, 4f and 4e; the accessibility rules hold ua1 and ua2; the well-tagged profiles hold wt1r and wt1a. A letter names a level: b promises the page always looks the same, a asks for the structure of the text as well, and u asks that every letter be traceable back to its character.

Each flavour is a profile carried as XML inside the command-line archive, one element per clause and test. Counting those elements gives the size of a verdict: 155 in 3a, 146 in 3b, 106 in ua1, 109 in the fourth part and 1 727 in ua2. A report produced with successes reported carries exactly that many rules, which is how a report is checked against the profile it claims to come from.

Rules of your own, run through the same program

Beyond the profiles it ships with, veraPDF extracts what a document holds as XML and applies a policy file to that extract — a Schematron document carrying assertions of your own. That is how the printing standard is measured here: eleven rules read off the published text, one verdict per rule, and a count at the end.

The two uses are kept apart, and the difference is stated wherever a figure rests on one of them. A profile that ships with the program gives an answer that is veraPDF's; a policy file gives an answer that is ours, produced by veraPDF's reading of the file.

verapdf --extract --policyfile pdfx4.sch --success -f 3b sheet.pdf

What a report holds

Every rule of a report carries the standard it comes from, the number of its clause and the number of the test inside that clause, the kind of object it applies to, and the sentence the profile states it in. A test that failed adds the object it failed on, written as a path through the document: the page, the annotation on it, the appearance of that annotation, the stream inside that appearance.

That path is what makes an answer something to act on. A report naming clause 6.2.2 test 3 of the fourth part, on the content stream of the appearance of the first annotation of the first page, names one object and one sentence of one text — which is a repair somebody can make the same afternoon.

How the engine is held to it

The two uses, the figures each of them produced, and the documents those figures were produced on.

The profiles are read as the source of a rule

A conformance rule can be written from a memory of the standard or read off a profile that states it. Here it is read. The profiles travel as XML inside the command-line archive, and opening one turns a question of interpretation into a lookup.

One example settled a real question. A document of the fourth archival part was to carry a link to a part of another document, an action of the kind the modern format calls GoToDp. Whether an archival document may carry one is a matter of reading. The profile of the fourth part answers in a line: its rule on actions lists the kinds allowed, and that one is among them, in all three flavours of that part. The engine's rule was written on that reading, and the document exercising it passes.

Reading the profiles is also what keeps the engine from insisting on something the text never asked for. A refusal nobody can point at is a refusal a customer cannot act on, so every rule the engine applies has an article behind it.

Every document goes in front of it

The second use is the witness. A document the engine writes is handed to veraPDF before anything is said about it, and what the checker answers is what this site publishes. Two of those runs are worth naming, because they carry their figures.

An invoice of three pages, laid on page templates as LibreOffice wrote them and carrying the data file of the invoice inside it: declared an archival document of the third part at level b, on 146 rules and 5 456 separate checks, with every check satisfied.
A document of the fourth part carrying a hierarchy of its own parts and a link into one of them: 109 rules out of 109, and every one of them held.

The examples published here go through it too

The archival documents in the catalogue of examples are put through the checker at both levels of the third part and against the accessibility rules, and it accepts them. The same holds for the twenty-six reference colour profiles run end to end: each went into an archival document, and veraPDF said which of them an archival document may state as its output intent.

A French translation of a document is put through it as well as the English one. Translating changes the text drawn on the page and the words filed inside the structure, so the run is worth making twice: the French archival form is declared conformant on the same 146 rules.

What veraPDF covers, and what is checked another way

The list of flavours is the list of what veraPDF decides: the archival family and the accessibility rules. That covers what an archive, an auditor or a public body asks for, and the engine is measured on both.

The printing family is decided elsewhere, and in two ways. Rules read off its published text are run over the finished file through the policy mechanism above, and the same page is written a second time by an altogether different program and compared point by point. The page on print-ready files says which part the engine writes and what it insists on before writing anything.

On the day, the printing works runs its own check on what it receives, as most of them do. That is a third pair of eyes, and it is the one that settles the matter.

Where to go next

What makes a document readable in twenty years, and by everybody What each archival claim asks for, and who supplies what An archival form the checker accepts How a file ready for the press is checked instead The twenty-six colour profiles the checker ruled on

See the prices See the examples

Where this information comes from

Texts read on 27 July 2026.

Who makes the free checker, and who pays for it: veraPDF — About the project Open Preservation Foundation and PDF Association
What we do about it: Who publishes the checker, who paid to build it, and under what licence it is given away. It is the whole basis of the claim that the verdict on our documents comes from outside.
How the free checker decides a document passes: veraPDF documentation — Validation Open Preservation Foundation and PDF Association
What we do about it: How the checker reaches a verdict, and the flavours it reaches one on. The calls shown on this page, and the rule counts each profile reports, are read off it and off the profiles themselves.
The standard for a PDF made to be kept, the part that carries an attached file: ISO 19005-3:2012 — Document management — Electronic document file format for long-term preservation — Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3) International Organization for Standardization — October 2012
What we do about it: The part behind the first figure on this page: the invoice of three pages is declared conformant to it, at level b.
The standard for a PDF made to be kept, fourth part: ISO 19005-4:2020 — Document management — Electronic document file format for long-term preservation — Part 4: Use of ISO 32000-2 (PDF/A-4) International Organization for Standardization — November 2020
What we do about it: The part behind the second figure, and the one whose profile lists the kinds of action an archival document may carry. That list is what the engine's own rule was written from.
The standard for a PDF a blind reader can read, first part: ISO 14289-1:2014 — Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1) International Organization for Standardization — December 2014
What we do about it: The accessibility rules the checker decides on beside the archival ones. The engine writes them, and the checker is what says so.