Most PDF/A failures come from the way the file was exported, not from the validator. Find out which PDF/A part and level you were asked for, match the error to its cause, fix that cause in the source document, and export again with the PDF/A option turned on. Then validate the new file, not the old one.
Patching the finished PDF by hand is the slow road. I have seen people type a PDF/A declaration into the metadata and wonder why the file still fails. The declaration is a claim. The validator checks the contents.
Step 1: confirm which PDF/A you were asked for
PDF/A is ISO 19005. It has four parts, and parts 1 to 3 add a conformance level marked by a letter. A file that passes PDF/A-2b can fail PDF/A-2a, because level a adds tagging rules. Ask the recipient for the exact label, such as "PDF/A-2b", before you fix anything.
| Part | Standard and base PDF | Levels | Header version expected |
|---|---|---|---|
| PDF/A-1 | ISO 19005-1:2005, based on PDF 1.4 | a, b | 1.4 or later |
| PDF/A-2 | ISO 19005-2:2011, based on PDF 1.7 | a, b, u | 1.6 or later |
| PDF/A-3 | ISO 19005-3:2012, as part 2 but allows attachments of any format | a, b, u | 1.6 or later |
| PDF/A-4 | ISO 19005-4:2020, based on PDF 2.0 | none; optional 4e and 4f variants | 2.0 |
The letters stack. Level b preserves how the pages look. Level u adds the rule that all text maps to Unicode, so it can be searched and copied. Level a adds tagged structure for accessibility on top of u. The PDF Association's overview lists the parts in more detail.
Step 2: match the error to its cause
Validators word their messages differently, but almost every failure lands in one of these groups.
| Error | What it means | Fix |
|---|---|---|
| Font not embedded | The file names a font but does not carry it | Use fonts that allow embedding and re-export with PDF/A on |
| Missing Unicode mapping | Text cannot be mapped to characters (levels u and a) | Replace symbol or decorative fonts, then re-export |
| No output intent, or device color without a profile | Plain RGB or CMYK with no ICC profile that says what the colors mean | Export with a PDF/A preset, which embeds an output intent |
| XMP missing or mismatched | The XML metadata block is absent or disagrees with the Info dictionary | Re-export from the source instead of editing metadata afterwards |
| Encryption present | The file has an open password or permission restrictions | Remove all security before export; PDF/A forbids it even without a password |
| Transparency (PDF/A-1) | Soft shadows, glows or see-through images | Use PDF/A-2 if allowed, or flatten the effects in the source |
| JavaScript or actions | Scripts or launch actions, usually from form features | Flatten or remove interactive features before conversion |
| Embedded files | Attachments the chosen part does not allow | Remove them, or use PDF/A-3 if the recipient accepts it |
Step 3: fix the source, then export again
- Keep the failing file and the full report. You will want to compare them with the new export.
- Open the source document. Swap fonts that cannot be embedded, delete attachments and scripts, and remove any password in Word, LibreOffice or your layout app.
- Export with PDF/A selected. In Word for Windows, open Options in the Save As dialog and tick ISO 19005-1 compliant (PDF/A); Microsoft's guide describes the option. LibreOffice has an archive (PDF/A) setting in its PDF export dialog where you pick the part.
- Or convert in Acrobat Pro. Its Preflight tool ships PDF/A profiles that convert a file and repair many problems. Treat the result like any other export and validate it.
- Or use Ghostscript. The pdfwrite documentation shows the command:
-dPDFA=2with a PDF/A definition file,PDFA_def.ps, that supplies the ICC profile. Skip the definition file and you get the first of my test files below. - Validate the exact file you will submit. Not the draft, not a copy that was opened and saved again.
If the document must be signed, sign last. Any conversion after signing breaks the signature.
Three test files, and what each one taught me
On 12 October 2026 I turned one short PostScript page into PDFs three ways with Ghostscript 10.08.0, built a fourth file by hand, and ran them through the PDFCheck PDF/A checker. The results below are the checker's own output.
- Ghostscript with
-dPDFA=2and no ICC profile. Declared: PDF/A-2b. Six indicators passed, one failed ("No PDF/A output intent and no ICC-based colour space found") and one warned ("No ICC profile detected"). qpdf confirmed the file has no OutputIntents entry at all. The same page made withPDFA_def.psand Ghostscript's sRGB profile passed both color checks. - A hand-built file declaring PDF/A-2b with Helvetica not embedded. Font Embedding failed with "1 font(s) not embedded: Helvetica". The declaration was there. The font was not.
- Ghostscript with
-dPDFSETTINGS=/prepressand no PDF/A option. All fonts embedded as subsets, XMP present, no encryption, and still a fail: "No pdfaid namespace found in XMP metadata".
File 1 is the one that changed how our checker works. It looks like PDF/A, it says it is PDF/A, and it is missing the output intent, the embedded profile that tells an archive what its colors mean. Until 12 October 2026 our screen had no output intent indicator and reported that file as passing. It fails it now. File 2 shows that a declaration proves nothing on its own. File 3 shows the reverse: a tidy file is not PDF/A until it is exported as PDF/A, because the declaration is the first thing archives look for.
What a quick pre-check can and cannot tell you
The PDFCheck checker reads eight indicators: the conformance declaration, whether an XMP stream exists, font embedding, encryption, PDF version against the declared part, JavaScript, output intent and ICC color profile. The overall line reads "PDF/A indicators pass" only when a declaration exists and no indicator failed. Warnings do not change the verdict.
Two limits are worth knowing. The declaration is matched in the file's raw bytes, so a declaration stored inside a compressed stream is not seen and the checker will report it missing. And the output intent check reads the catalog and color-space dictionaries, not the drawing instructions inside each page, so a page that paints in device RGB can still pass.
The checker also does not look at transparency, blend modes, optional content, annotation appearance streams, actions other than JavaScript, Unicode mapping for level u, tagging for level a, attachment rules for PDF/A-3 and 4f, or whether XMP and the Info dictionary agree. For a formal result, run veraPDF, the open-source validator maintained with the PDF Association. It implements the testable rules of PDF/A parts 1 to 4. If your recipient names a different validator, that one decides.
Why does one validator pass my file and another fail it?
They may test different profiles, different rule versions, or treat edge cases differently, and a pre-check tests far fewer rules than a full validator. Our own checker passed file 1 one day and failed it the next, after we added an indicator. Run the validator your recipient uses, on the final file, and keep its report with the submission.
If the font list is the problem, the font checker names each font that is not embedded. If the file is encrypted, remove the password with the password tool before you re-export, since PDF/A does not allow encryption of any kind.