PDF/A Validator

How to check PDF/A compliance in your browser

Drop the file on the panel above. The result appears in a second or two, with one row per requirement and a plain sentence explaining each one.

Nothing is uploaded. The file is read inside the tab, which is unusual for this kind of tool and deliberate on our part. The documents people validate are contracts, medical records, tax filings and evidence bundles. Those are exactly the files you least want sitting in a stranger's temporary folder, however short the retention policy claims to be.

The trade-off is a size ceiling. Because your browser holds the whole document in memory, very large files will struggle on a modest laptop. That is a real limit and we would rather state it than let you discover it with a frozen tab.

Is my PDF actually PDF/A compliant?

Two different questions hide inside that one, and separating them solves most confusion.

The first is what the file claims. A PDF/A document carries a small block of XMP metadata saying which part of the standard it belongs to. We show that as the declared level. The second is whether the file delivers on the claim, which is what the individual checks answer.

Those two come apart more often than you would hope. Anything can write a pdfaid block into a file's metadata — it is a claim, not a guarantee. We have seen documents proudly labelled PDF/A-2b with half their fonts missing, produced by converters that relabelled the file and changed nothing else. That is why the declared level sits apart from the verdict on this page instead of standing in for it.

What a PDF/A conformance checker actually looks at

Five structural facts carry most of the weight, and they are the five that cause most rejections.

• Identification. The pdfaid block in the XMP metadata. Without it the file is an ordinary PDF, however correct everything else is.
• Output intent. An embedded ICC colour profile recording what the colours meant. Missing profiles are the single most common silent failure.
• Font embedding. Every font the document uses has to travel inside it. We list them individually, because knowing which font failed is the difference between a two-minute fix and an afternoon. If yours comes back short, the fonts not embedded error walks through the causes.
• Encryption. Forbidden outright, in every part of the standard.
• Executable and external content. JavaScript, launch actions, embedded audio, video and 3D objects.

Attachments and transparency get judged against the part you claim rather than universally. A spreadsheet embedded in a document is perfectly valid as PDF/A-3 and invalid as PDF/A-1, so those show as warnings with the reason attached. The differences are laid out in PDF/A-1b versus PDF/A-2b.

How this compares with a veraPDF validation report

veraPDF is the reference implementation, backed by the PDF Association, and it is what archives and national libraries actually run. If you need a formal audit, use it.

It is also a Java application you install, point at a file and read an XML report from. That is entirely reasonable for a records team processing thousands of documents, and completely disproportionate when you have one thesis to submit on Friday.

So the honest framing is this. We check necessary conditions — the things that fail every validator, every time. veraPDF additionally applies rules to page content streams, which requires a rendering pass no browser tool performs. A failure here is definitive. A clean pass here means nothing obviously wrong, which is usually enough to submit with confidence and occasionally is not.

What our PDF/A validator finds most often

After looking at a lot of rejected files, the same few causes keep coming back.

A missing output intent leads by a distance. The file converted, the fonts embedded, everything looks right, and the colour profile was never attached. Whoever ran the conversion had no idea, because the tool reported success.

One unembedded font out of twelve comes second, and it is usually a symbol or a bullet glyph nobody remembers using. The document looks perfect and fails anyway.

A file that was only relabelled is third — the counterfeit described above. Leftover encryption is fourth, generally on a document that was password-protected years ago by someone who has since left. And the right file at the wrong level is fifth, which is not a validity problem at all: a valid PDF/A-2b sent to a system that only takes PDF/A-1b.

Reading the result without panicking

A red row is not a broken document. It is a list of what to fix, and most items take one pass through a converter.

Missing fonts, a missing output intent or missing identification all resolve by running the file through our PDF/A converter at the level you were asked for. Encryption has to come off first. Attachments and transparency need a decision about which part of the standard applies, not a fix.

One thing a clean result never tells you is whether the document is accessible. Conformance level b covers visual reproduction only. Screen-reader support lives in level a, which needs a tagged structure the authoring program has to create. A file can be flawless PDF/A-2b and unusable with assistive technology.

If the file turns out to be archival when you wanted an editable one, that is the opposite problem and it has its own answer: make an archived PDF editable again, described in more detail in editing a PDF/A without breaking it.

Check before you submit, not after

A PDF/A validator earns its keep in the thirty seconds before you upload something, not in the week after a rejection. Run the file, read the rows, fix whatever is red, and send it knowing what is inside it.

New to the format and unsure what any of this is for? Start with the PDF/A standard explained. Preparing a university deposit? The Word route has traps of its own, covered in the thesis submission workflow. Working from paper originals? Read OCR a scan before archiving first, because a compliant scan is still an unsearchable one.