Direct answer: preserve the original, run it through PDFCheck, and read PDF Version in Quick Overview or Technical Specifications. Compare that value—such as 1.4, 1.7, or 2.0—with the recipient's exact rule. If it does not match, re-export a copy from the source application with the required compatibility, then check the copy again. Do not change `%PDF-1.x` in a text editor: the label alone does not prove that the file's features match that version.
First-screen decision map
| What the recipient says | Check first | Safe next action |
|---|---|---|
| “PDF version unsupported” | Reported PDF version and the portal's allowed versions | Re-export a copy with an accepted compatibility setting; retest |
| “PDF/A required” | The exact profile, such as PDF/A-1b or PDF/A-2u | Use a conforming export and the PDF/A Validator; a version number is not enough |
| “Invalid PDF” | File completeness, encryption, structure, size, and the real error text | Run the PDF Validator, preserve the original, and re-export from the source application when possible |
| “Created in an unsupported Acrobat version” | Whether the rule means the PDF file version or the Acrobat application release | Ask for the permitted PDF compatibility or named standard before converting |
Keep the original while you diagnose. This matters most for signed PDFs: rewriting or re-exporting changes bytes and can invalidate or remove signature evidence. Check a preserved original with the PDF Signature Checker before creating a derivative.
PDF version, PDF/A, and Acrobat version are different
PDF file version
A base specification label such as PDF 1.4, 1.7, or 2.0. It indicates the file's declared compatibility level, but not every feature actually used.
PDF/A profile
A constrained archival standard such as PDF/A-1b or PDF/A-2u. Conformance requires more than a compatible base version.
Acrobat version
The release of Adobe's application. “Acrobat 8” and “PDF 1.7” are related through compatibility settings, but they are not interchangeable labels.
The PDF Association's version guidance explains why a PDF header can be overridden by the document Catalog and why the stated version may still under-report features used in the file. The Library of Congress PDF 1.7 description also documents the Catalog version mechanism. That is why a robust parser is safer than reading only the first line.
How to check the PDF version with PDFCheck
- Save the original separately. Work on a copy only after you know the recipient's exact requirement.
- Open PDFCheck. Use a file you are authorized to upload and that fits your privacy policy.
- Upload the PDF and wait for the analysis. Confirm that the report names the file you intended to inspect.
- Read PDF Version. It appears in Quick Overview and again under Technical Specifications.
- Record related risks. Note encryption, forms, embedded fonts, signatures, JavaScript, attachments, and structure warnings before conversion.
- Compare with the exact rule. “PDF 1.4 only,” “PDF 1.7 or earlier,” and “PDF/A-2u” demand different actions.
- Re-export a copy, then rerun the checks. Finally test the real portal; a local result cannot guarantee recipient acceptance.
PDFCheck capability boundary: PDFCheck reports the version parsed from the file and shows metadata, basic structure, and selected risk indicators. It does not certify that every object obeys that version, prove PDF/A, PDF/X, or PDF/UA conformance from the version label, safely downgrade the file, or guarantee that a court, archive, printer, bank, or other portal will accept it. Use the recipient's validator as the final gate.
What common PDF versions mean in practice
| Version | Typical compatibility context | Do not assume |
|---|---|---|
| PDF 1.3 | Legacy workflows that avoid newer transparency features | That forcing 1.3 is lossless; transparency may be flattened |
| PDF 1.4 | A common legacy portal or older-viewer requirement | That “1.4” means PDF/A-1 or that signatures survive re-export |
| PDF 1.7 | Broad modern compatibility; standardized as ISO 32000-1 | That every PDF/A profile or recipient accepts it |
| PDF 2.0 | The current ISO 32000-2 specification family | That every legacy portal, viewer, or production system supports it |
For the standards behind these labels, use the PDF/A Validator for a conformance screen and consult the PDF Association's current ISO 32000-2 resource.
Safe recovery when the version is rejected
- Capture the exact error. Record the portal name, permitted version/profile, file-size limit, and whether validation happens before or after upload.
- Inspect the original. Record its reported version, signature state, encryption, fonts, forms, attachments, and page count.
- Return to the source application when possible. Export a new copy with the required compatibility preset. This is safer than patching the PDF header.
- Review conversion trade-offs. Adobe's PDF conversion settings show that compatibility is one of several creation controls. Its advanced optimization guidance warns that compatibility changes can accompany downsampling, font changes, transparency flattening, or object removal.
- Retest the derivative. Check version, openability, page appearance, fonts, links, forms, accessibility, and signature status. Run a final structural screen with the PDF Validator.
- Upload the tested copy. Portal acceptance is the final proof. Keep the original and the accepted derivative with unambiguous filenames.
Failure states and recovery actions
| Failure | Likely issue | Recovery |
|---|---|---|
| Header says 1.4, checker says 1.7 | The Catalog may override the header, or newer features may be present | Trust a parser that evaluates the document; re-export from source instead of editing the header |
| Version matches, portal still rejects | The rule may also require PDF/A, embedded fonts, no encryption, size limits, or valid structure | Run the PDF and PDF/A validators; compare every stated portal rule |
| Re-export changes appearance | Transparency, color, fonts, layers, or images changed during compatibility conversion | Compare every page with the original and adjust export settings or use the source app |
| Signature becomes invalid or disappears | The signed bytes were changed or the document was recreated | Return to the signed original; ask the recipient whether a newly exported copy must be signed again |
| Online checker cannot open the PDF | The file may be encrypted, incomplete, malformed, or blocked by upload policy | Use an authorized offline workflow, obtain a clean original, or validate before trying another conversion |
Realistic examples
A court portal asks for PDF 1.4
The document reports PDF 1.7 and carries a digital signature. Preserve the signed file and the rejection message. Do not “downgrade” the signed bytes. Ask whether the portal accepts a newly exported and newly signed copy, then follow its signing order exactly.
An archive asks for PDF/A-2u
A report showing PDF 1.7 does not prove PDF/A-2u. Export to the named profile, run the PDF/A Validator, fix font/metadata/Unicode failures from the source, and validate the final file again. The Library of Congress describes PDF/A-2 as a constrained standard based on PDF 1.7.
A print workflow rejects PDF 2.0
Ask the printer for its preferred PDF/X profile or export preset rather than guessing “PDF 1.7.” Re-export a copy from the layout source, then check fonts, transparency, color, page boxes, and a proof. A lower version label alone does not make a production-ready print file.
Offline check when you cannot upload the file
On a trusted machine with Poppler installed, run pdfinfo document.pdf and read the `PDF version` line. Use an explicit local filename and keep sensitive output out of tickets and chat. This is preferable to opening the first line in a text editor because a PDF 1.4-or-later Catalog can override the header.
If neither an authorized local tool nor PDFCheck can process the file, stop converting copies blindly. Obtain the original from its source, confirm encryption and permissions, and use the recipient's approved validation workflow.
Final checklist
- □ The original remains unchanged and separately named.
- □ The exact recipient requirement is recorded: base version, PDF/A/PDF/X profile, and any other limits.
- □ The reported PDF version came from a parser, not only the header text.
- □ The derivative was re-exported from a trusted source or converter, not relabeled.
- □ Page appearance, fonts, links, forms, accessibility, encryption, and signatures were retested where relevant.
- □ The recipient portal accepted the exact final file.
The reliable workflow is short: preserve, inspect, match the exact rule, re-export a copy, retest, and submit. The version number is a useful diagnostic field—not a compatibility certificate.