PDF & Documents
PDF/A readiness check: find the blockers before you validate
Upload a PDF and see in plain language whether it is encrypted, carries embedded files or JavaScript, and which metadata fields it has. These are frequent reasons a file fails PDF/A validation or is sent back by an archive.
or drop it here
- Up to 500 pages
- Not encryptedThe file opens without a password. PDF/A does not allow encryption.
- Embedded files foundAttachments travel inside the PDF. PDF/A-1 and PDF/A-2 restrict them, so remove or replace them before validating.
- No JavaScriptNo document scripts were found. PDF/A does not allow them.
- Metadata fields/Author, /CreationDate, /Producer, /Title
- SHA-256 fingerprint9f2c41…e07a
You download archive-readiness.json and manifest.json. Sample values for illustration.
How to use it
- 1
Add one PDF
There is nothing to set. The file is read, not changed.
- 2
Read the findings
Encryption, embedded files, JavaScript, page count and metadata fields, each in one line.
- 3
Fix, then validate
Remove what blocks archiving, then run a formal PDF/A validator or hand the file to your archive.
What the readiness check looks at
Five things read from your PDF
You upload one PDF of up to 500 pages. The check reads whether the file is encrypted, whether it contains embedded files or JavaScript, how many pages it has and which fields its document information holds, such as /Title, /Author or /Producer. A file that cannot be opened for inspection is rejected rather than half checked. Your PDF is not converted or changed.
Why these findings matter for PDF/A
PDF/A is meant for files that must still open the same way in many years. Encryption, scripts and some kinds of attachments work against that, so validators and archive intakes reject them. Finding them before a formal validation saves a round of back and forth.
What you download
archive-readiness.json lists the findings and the SHA-256 fingerprint of your PDF, a code computed from its exact bytes. manifest.json describes the package. Compute the SHA-256 of your own copy and compare the values to show the report belongs to that file.
What it does not do
It does not check fonts, colour profiles or XMP metadata clause by clause, and it gives no PDF/A pass or fail. For that, use a formal validator such as veraPDF with the PDF/A part and level your archive asks for.
Questions before you run it
Is this a PDF/A validator?
No. It is a readiness check that runs before a formal validation. It reports encryption, embedded files, JavaScript, page count and metadata fields, which are common reasons a file fails PDF/A. It does not give a pass or fail per PDF/A clause.
Where do I get a formal PDF/A verdict?
Use a validator built for the standard, such as the open-source veraPDF, and pick the PDF/A part and level your archive asks for. Fix the findings from this check first, then run the validation.
Does this convert a PDF to PDF/A?
No. It reads the file and reports what would complicate archiving. It does not change your PDF and produces no converted version.
What happens with a password-protected PDF?
Encryption is reported in archive-readiness.json as a finding. A file that cannot be opened for inspection is rejected rather than half checked.
How do I prove the report belongs to the file I sent?
The report records the SHA-256 fingerprint of your PDF. Compute the SHA-256 of your own copy and compare the two values before you pass the report on.