PDF/A Compliance Checklist: A Practical Guide
PDF/A (ISO 19005) is the PDF subset built for long-term archiving: a file that renders the same way in 20 years as it does today. Use this checklist to decide which flavor you need, convert correctly, and prove it before you ship.
1. Confirm You Need to Act
☐ A regulation, contract, or customer requires PDF/A (courts, government records, healthcare, finance, and public-sector archives commonly do)
☐ You need documents to look identical on any viewer, years from now, without depending on fonts or files outside the PDF
☐ You produce Factur-X or ZUGFeRD e-invoices, which must be PDF/A-3
☐ You archive or exchange PDFs that use encryption, JavaScript, linked media, or non-embedded fonts today
If any of these apply, plan for PDF/A conformance rather than treating it as a nice-to-have.
2. Choose the Right Part and Level
PDF/A has four parts, each tied to a PDF version. Pick the lowest part that meets your requirement, then choose a conformance level.
☐ PDF/A-1 (based on PDF 1.4) — the most restrictive: no transparency, no layers, no embedded files; levels A and B
☐ PDF/A-2 (based on PDF 1.7) — adds transparency, layers, JPEG 2000, and embedding of other PDF/A files; levels A, B, and U
☐ PDF/A-3 (based on PDF 1.7) — same as A-2, but allows embedding files of any format; required for Factur-X/ZUGFeRD
☐ PDF/A-4 (based on PDF 2.0) — the current part; no A/B/U levels, with optional PDF/A-4f (embedded files) and PDF/A-4e (engineering content)
For parts 1 to 3, also choose a conformance level:
☐ Level B (basic) — guarantees visual reproducibility only
☐ Level U (Unicode) — level B plus Unicode mapping, so text can be reliably searched and copied (part 2 and 3 only)
☐ Level A (accessible) — level U plus tagged structure and logical reading order
☐ You've confirmed which part and level your regulator, customer, or downstream system actually specifies, since requirements are often written as a single value such as "PDF/A-2b"
Not sure PDF/A is the right standard? PDF/A, PDF/X, and PDF 2.0 solve different problems. Read PDF/A vs. PDF/X vs. PDF 2.0: Which Standard Do You Need? to match the standard to your workflow.
3. Understand What PDF/A Requires
A PDF/A file must be fully self-contained. These are the rules that most often cause a file to fail.
☐ Fonts: every font used is embedded, including those used only in annotations and form fields
☐ Color: all color is device-independent or covered by an output intent (an embedded ICC profile)
☐ No encryption: no passwords and no permission restrictions
☐ No active content: no JavaScript, no launch actions, and no executable files
☐ No external dependencies: no linked or external content, and no reliance on external fonts, profiles, or streams
☐ No LZW compression: use Flate or another permitted filter
☐ Metadata: an XMP metadata stream is present, identifies the part and conformance level, and matches the Document Info dictionary
☐ Annotations: every visible annotation has an appearance stream
☐ Transparency: not allowed in PDF/A-1; allowed in parts 2, 3, and 4
☐ Embedded files: not allowed in PDF/A-1; PDF/A files only in A-2; any format in A-3 and PDF/A-4f
4. Prepare the Source Document
Fixing problems before conversion is cheaper than repairing them afterward.
☐ All fonts are available to your authoring or conversion tool and licensed for embedding
☐ Images use RGB, CMYK, or gray color spaces your conversion tool can map to an ICC profile
☐ Transparency is removed or flattened if your target is PDF/A-1
☐ Form fields, comments, and other annotations have visible appearances, or are flattened if they are not needed
☐ Passwords, permissions, and digital signatures are handled up front (conversion invalidates existing signatures, so sign after converting)
☐ Links to external media, audio, video, and 3D content are removed or replaced with static images
☐ For level A: headings, lists, tables, and alternate text exist in the source so tagging can carry them through
5. Build Toward a Compliant PDF
☐ Your converter targets the exact part and level you chose in section 2
☐ Non-embedded fonts are embedded or substituted, and text still maps to Unicode
☐ An output intent with an embedded ICC profile (for example sRGB) is added, and colors are converted to match
☐ Disallowed features are removed: encryption, JavaScript, LZW filters, and external references
☐ XMP metadata includes pdfaid:part and pdfaid:conformance (the level is omitted for PDF/A-4), and its title, author, and dates agree with the Document Info dictionary
☐ Custom XMP properties are declared in a PDF/A extension schema, or removed
☐ For level A: the document is tagged, marked as tagged, has a logical reading order, and declares its natural language
☐ For PDF/A-3 and PDF/A-4f: every embedded file has a MIME type and an AFRelationship value
☐ The converted file is saved as a new copy, so the original stays untouched
6. Validate Before You Ship
☐ Every finished file is run through a PDF/A validator, such as the open-source veraPDF or the preflight tool in your PDF software
☐ The validator is set to the same part and level you targeted, not just "PDF/A" in general
☐ A clean report is required: any failed rule means the file is not PDF/A, however it looks on screen
☐ Failures are traced to a root cause (fonts, color, metadata, or annotations) and fixed in the pipeline, not patched file by file
☐ You've tested a representative sample: scanned pages, forms, large images, non-Latin text, and files with attachments
☐ Validation runs automatically in your build or release process, so a regression fails the build
☐ You've checked how the file reads back: text is searchable and copyable, and pages render identically in more than one viewer
7. Plan Your Technical Approach
☐ You've decided whether to build PDF/A conversion in-house or use a PDF SDK or converter that handles fonts, color profiles, and metadata for you
☐ Conversion happens as the last step of your pipeline, since editing, merging, or signing a file afterward can break conformance
☐ Any later modification re-runs conversion and validation
☐ You've planned for files that cannot be converted (corrupt or password-protected inputs) with a clear error path
☐ You've estimated the file-size impact of embedding fonts and ICC profiles, and set storage and bandwidth expectations
☐ If you also produce Factur-X or ZUGFeRD invoices, you've confirmed which parts of this PDF/A-3 pipeline can be reused, and which parts (the XML invoice data) your invoicing logic must still generate
Converting a large archive? Manual conversion doesn't scale to hundreds of thousands of files. See Compliance Archiving: How to Convert PDFs to PDF/A at Scale for how to automate bulk PDF/A conversion with PDF Optimizer.
PDF/A conformance is binary: a file either passes validation or it does not. Build validation into the pipeline from day one. Get a free trial of Adobe PDF Library and browse our GitHub repository for code samples in your preferred programming language.