The September release of JPedal (2026.09) adds PDF to PDF/A-3b conversion. JPedal also validates PDFs against the Arlington PDF Model.
What is PDF/A compliance?
A PDF/A compliant file meets the requirements of ISO 19005 for a specific part and conformance level, such as PDF/A-3b. The file is self-contained: every font is embedded, nothing depends on external resources, and there is no encryption or JavaScript. What is PDF/A? covers the versions and conformance levels in more detail.
Archives and courts specify PDF/A because their documents have to render the same way decades from now. PDF/A-3 also allows file attachments, which is how hybrid invoice formats such as Factur-X and ZUGFeRD carry machine-readable XML inside the human-readable invoice.
Why files lose PDF/A status
A file isn’t compliant just because its metadata says so. A recent PDF Association article, Your file says it’s PDF/A. That was three tools ago., describes how ordinary operations such as compressing and merging rewrite a PDF. The rewrite can drop the structures that made the file compliant while keeping the metadata that claims it still is. Nothing downstream notices until someone validates the file with a tool such as veraPDF. A converter that reports success without validating proves nothing.
Converting PDF to PDF/A-3b
JPedal checks a PDF against the PDF/A-3b requirements and tries to rewrite whatever falls short. Each conversion ends in one of two outcomes:
- Converted: JPedal writes a PDF/A-3b file and returns a list of the changes it made to get there.
- Not converted: If the file has problems JPedal can’t fix, it writes no output and returns the issues that blocked conversion.
Keep the change list with each converted file, since some changes are lossy.
Some details on the conversion itself:
- It runs in pure Java in your own JVM on Java 17 and above.
- It’s included in every JPedal license.
- Level B is the only conformance level currently supported.
- Encrypted files can be converted if you supply the password. PDF/A doesn’t allow encryption, so the converted file won’t be encrypted.
- Conversion is available from the Java API and from the command line.
The PDF/A-3 tutorial has the code for both.
Validating with the Arlington PDF Model
The Arlington PDF Model is the PDF Association’s machine-readable definition of the objects in the PDF specification. It covers which keys each object can have, what types their values must be, and which values are permitted.
JPedal’s validator checks a file against that model and reports every issue it finds, each with a severity (ERROR, INFO or WARNING), the path to the offending object and the rule it breaks. For example, a page whose font dictionary has a Widths array of the wrong length gets an error pointing at that exact object. The model comes bundled with JPedal for use from the Java API. To use the validator from the command line, download the TSV files from the PDF Association’s repository.
Arlington checks a file against the base PDF specification, not PDF/A. Where it helps with PDF/A is diagnosing files that won’t convert: structural errors in the source often explain the issues the converter reports. To confirm that a converted file meets PDF/A-3b, use veraPDF.
The Arlington validation tutorial covers the Java API and command-line usage.
For more on PDF to PDF/A conversion in JPedal, see the Convert PDF to PDF/A in Java page.