PDF/A Readiness Check - Free Online Browser Tool

Check a PDF against the things PDF/A requires - metadata, fonts, tagging, output intent - and get a report.

PDF/A is the flavour of PDF meant to still open in twenty years. It is what an archive asks for, what a regulator asks for, and what a print shop assumes when they accept a file without asking questions. The requirements are specific, and most of them are things the file either states about itself or plainly lacks. This tool reads those things. It looks for the XMP identification metadata that carries the pdfaid:part and pdfaid:conformance declaration a validator tests against. It checks for an output intent, without which a printer is guessing what your colours mean - which is how a brand colour drifts between one printer and the next. It counts font objects against embedded font programs, because a font that is not embedded is a font the reader has to happen to have installed. It checks for a structure tree, for a document identifier, and for the two things PDF/A forbids outright: encryption and JavaScript. Each result is a pass, a warning or a failure with the reason and, where there is one, what to do about it. The report is a standalone HTML file you can send to whoever owns the document. Now the limit, and it is the important one. This is a readiness check, not a certification. A file can pass every signal here and still fail a formal PDF/A validation, because the standard also covers things that cannot be read from the outside - colour spaces, transparency groups, annotation rules, the exact conformance of an embedded font. Read a clean report as "worth validating properly", not as "validated". What it is genuinely good at is telling you which specific thing is missing before you pay anyone to tell you the same thing in a longer document. The file is read in your browser and never uploaded, so a document under embargo can be checked without it going anywhere.

This pdf/a readiness check utility runs completely inside your web browser. Your document is opened locally and processed on your own device using JavaScript and WebAssembly, so your file is never uploaded to any server. There is no signup, no watermark and no limit on how many documents you can handle.

  • 100% client-side - files never leave your device
  • Instant processing, no upload wait
  • Works on desktop, tablet and mobile
  • Free forever, no account required

Common next steps: Accessibility Checker (PDF/UA), CMYK Printer Calibration Control Patches, Extract Metadata, Document Statistics.

How to Use the PDF/A Readiness Check Tool

Five steps, and the whole thing runs locally on your own device.

  1. Drop in the PDF

    One file. The check reads the file's own bytes, including the compressed object streams where a modern PDF keeps its metadata.

  2. Check the identification metadata

    PDF/A is declared in the XMP packet. No pdfaid:part and pdfaid:conformance means the file is not claiming to be PDF/A, which is a failure rather than a warning.

  3. Check fonts, tagging and the output intent

    Fonts counted against embedded font programs, a structure tree for headings and table headers, and an output intent so a printer is told what the colours mean.

  4. Check what PDF/A forbids

    Encryption and JavaScript are both hard failures. A validator has to be able to read the whole file, and an archived file must not run code.

  5. Save the report

    A single HTML file with every check, its result and its fix. Send it to whoever can make the change instead of describing the problem in an email.

Frequently Asked Questions

Is this a real PDF/A validation?

No, and the report says so on its face. A formal validation uses a dedicated validator that checks the parts of the standard which cannot be read from outside the file - colour spaces, transparency groups, annotation conformance, and whether an embedded font really is embedded correctly. This checks the signals a file states about itself, which is the part that catches the ordinary reasons a document is rejected, and tells you which one applies to yours.

My file has XMP metadata but is still reported as not PDF/A. Why?

Because metadata on its own is not the declaration. PDF/A identification lives in the XMP packet as a pdfaid:part (for example 2b) and a pdfaid:conformance entry, and the tool distinguishes the two cases explicitly. Metadata without a pdfaid entry means the file carries descriptive information but does not claim to be PDF/A, which is the honest reading.

Why is a missing output intent only a warning?

Because how much it matters depends entirely on what the file is for. A document that will only ever be read on screen loses nothing without one. A file going to a commercial printer can have its colours interpreted differently, and a brand colour that shifts between two printers is a real problem. The check tells you which case you are in rather than failing you for the one that does not apply.

What if a font cannot be embedded?

Then the file will not pass PDF/A, and no tool can change that - a font licence can forbid embedding, and that restriction is the usual reason. The report names the count so you know how many fonts are affected. If it matters, the file has to be built with a font whose licence permits embedding, which usually means a different typeface than the one you wanted.

Does my file get uploaded anywhere?

No. The bytes are read in this tab and the checks run there. That matters more than usual for this particular tool: the documents people most need to check against an archival standard are frequently the ones still under embargo.