How to Check if a PDF Is PDF/UA Compliant (Free Checker)
What PDF/UA-1 and PDF/UA-2 require, how to test a PDF against both for free with veraPDF, what the common failures mean, and how to fix them at the source.
A procurement form asks whether your documents are “PDF/UA compliant”. A customer using a screen reader writes in to say your invoices read as a jumble. An accessibility audit lists your PDFs as a finding. In each case the first question is the same: do these PDFs actually conform, and if not, what is wrong with them?
You can find out in under a minute with our free PDF/UA checker. Drop in a PDF and it is tested against PDF/UA-1 and PDF/UA-2, with every failed requirement explained in plain English. This post covers what the checker tests, how to read the result, and how to fix the usual failures.
What PDF/UA is
PDF/UA (Universal Accessibility) is the ISO standard for accessible PDF, ISO 14289. It turns “accessible” into requirements a file either meets or does not:
- Tags. The PDF carries a structure tree, so a screen reader knows what is a heading, a paragraph, a list, a table or a figure, and in what order to read them.
- Alternative text. Every meaningful image has a description. Decorative ones are marked as decoration.
- Decoration marked as such. Page headers, footers, borders and background shapes are marked as artifacts, so they are skipped rather than read out on every page.
- Language and title. The document says what language it is in, so text is pronounced correctly, and the reader shows its real title instead of a file name.
- Fonts that can be read aloud. Fonts are embedded, and every character maps to Unicode.
There are two versions:
| PDF/UA-1 | PDF/UA-2 | |
|---|---|---|
| Standard | ISO 14289-1 (2012, revised 2014) | ISO 14289-2 (2024) |
| Built on | PDF 1.7 | PDF 2.0 |
| Used by | Most accessibility checklists and procurement rules today | Newer requirements, and anyone standardising on PDF 2.0 |
PDF/UA-2 needs a PDF 2.0 file, so a PDF/UA-1 file almost always fails PDF/UA-2 on its version alone. That is expected: check against the standard you have been asked for.
Checking a PDF
- Open the PDF/UA checker.
- Drop in a PDF of up to 20 MB and complete the quick human check.
- Read the report.
The check runs on veraPDF, the open-source validator developed with the PDF Association, using its official PDF/UA-1 and PDF/UA-2 profiles. Your file is deleted as soon as it has been checked, and you do not need an account.
The report has three parts:
- A verdict for each standard. Pass, or the number of requirements not met.
- Facts about the file. PDF version, page count, whether it is tagged, its language and its title. An untagged PDF is the most common reason for failure, and this tells you at a glance.
- What to fix. Each failed requirement, with what it means, how to fix it, and the clause in the standard.
The failures you will see most
| Report says | What it means | Fix |
|---|---|---|
| The PDF is not tagged | No structure at all. Screen readers fall back to guessing | Export again with an accessible PDF option, or tag it in Acrobat |
| Untagged content | Some text or shapes are neither tagged nor marked as decoration | Usually headers, footers and borders. A good export marks them as artifacts |
| Image without alternative text | A figure has no alt text | Add alt text in the source (alt="…" in HTML, Alt Text in Word) |
| Missing XMP metadata / Not marked as PDF/UA | The file does not declare PDF/UA, or has no title metadata | Set a title and export with the PDF/UA option |
| Heading levels skip | H1 then H3, or no H1 at all | Use heading levels in order |
| Document language missing | No language is set | Set the document language before exporting |
| Font not embedded | A font is not inside the file | Turn on font embedding when exporting |
| Link not tagged | A link sits outside the tag tree, often in a repeated header or footer | Tag links, and keep them out of page furniture |
Almost all of these are best fixed in the source document rather than in the PDF. Correcting tags by hand in a PDF editor works, but the next export brings the problem back.
What a pass does and does not mean
A pass means the file meets every PDF/UA requirement a machine can test. Some requirements need a person to judge: whether the alt text actually describes the image, whether the reading order makes sense, and whether colour alone carries meaning. For documents with legal accessibility obligations, also listen to a sample with a screen reader.
Different checkers can also disagree at the edges. PAC, Adobe Acrobat’s accessibility checker and veraPDF test similar rules in their own ways. If someone gives you a specific tool to satisfy, check with that tool too.
If you generate PDFs from code
Most PDFs that fail were produced by a pipeline that never tagged them: a headless browser, a reporting library, an invoice system. Fixing them afterwards is slow. It is much easier to produce conforming files in the first place.
PodPDF does this from HTML, Markdown and templates. Add one field to a request:
curl -X POST https://api.podpdf.com/quickjob \
-H "X-API-Key: $PODPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"input_type": "html",
"html": "<html lang=\"en\"><head><title>Invoice INV-1042</title></head><body><h1>Invoice</h1>…</body></html>",
"pdf_standard": "pdf/ua-1"
}' \
-o invoice.pdfPodPDF tags the document, marks page furniture as decoration, sets the language and title, writes the metadata, and checks the result with veraPDF. The verdict comes back in the X-PDF-Conformance header. Use "pdf/ua-2" for a PDF/UA-2 file, written as PDF 2.0. The built-in templates pass both standards. With your own HTML, the parts only you control still matter: alt text on images, real headings, and <th> cells in tables. The feature is in alpha; the accessible PDFs guide has the details.
Try it
Check a PDF now. It is free, it takes a few seconds, and it tells you exactly what to fix.