How to downgrade a pdf to an earlier version for old readers
- Step 1Find out which version the reader supports — Check the reader's documentation or vendor notes for the highest PDF version it handles. If you can't find it, start at the highest plausible value and step down: try 1.6, then 1.5, then 1.4. 1.4 is the widest-compatibility floor because it forces the pre-1.5 serialization.
- Step 2Open the converter and drop the incompatible PDF — Load the file into the PDF Version Converter. Everything runs in your browser through pdf-lib — the document is not uploaded. One file at a time.
- Step 3Select the target version in the dropdown — The single control lists PDF 1.4, 1.5, 1.6, and 1.7 (default 1.7). Pick the version the reader needs. Remember: only 1.4 turns object streams off; 1.5 and 1.6 keep the compressed structure.
- Step 4Run the conversion — Each page is copied into a new document, the file is saved at the chosen version (object streams off for 1.4, on for 1.5+), and the header is patched to
%PDF-x.y. Text and images are preserved. - Step 5Test in the actual reader that failed — Open
<name>.version-converter.pdfin the specific legacy reader or embedded component, not just any viewer. Modern viewers open everything, so they can't confirm the fix worked for the old one. - Step 6Step down a version if it still fails — If 1.6 didn't load, re-run on the original and target 1.5, then 1.4. If even 1.4 fails, the blocker is a content feature, not the version — see the edge cases below.
Which target should an old reader get?
Pick the highest version the reader supports. Only 1.4 forces the pre-1.5 serialization.
| Symptom in the old reader | Best target | Why |
|---|---|---|
| 'Damaged' / 'cannot parse' on a 1.7 file | 1.4 | These are object-stream / compressed-xref parse failures; only 1.4 turns object streams off. |
| Opens but warns about an unsupported version | 1.5 or 1.6 (highest the reader allows) | The structure is fine; only the header version flag is too new. Keep object streams for smaller output. |
| Reader is documented as 'PDF 1.6 max' | 1.6 | Match the documented ceiling exactly; don't go lower than needed. |
| Reader is a very old Java/embedded engine | 1.4 | Safest floor; widest support across pre-2005 engines. |
| Fails even at 1.4 | Version conversion won't fix it | The blocker is a content feature (e.g. JPEG2000 image, transparency); needs re-encoding, not a version change. |
Object streams by target version
The single most important difference between the targets, taken straight from the converter's behaviour.
| Target | Object streams | Cross-reference form | Effect on old readers |
|---|---|---|---|
| 1.4 | OFF | Plain xref table + trailer | Readable by pre-1.5 engines; the real compatibility fix |
| 1.5 | ON | Compressed xref stream | Only lowers the header; pre-1.5 readers still can't parse it |
| 1.6 | ON | Compressed xref stream | Same as 1.5 structurally; just a different header flag |
| 1.7 | ON (default) | Compressed xref stream | Modern baseline; no downgrade |
Cookbook
Realistic 'old reader' situations and which target actually resolves each one.
Legacy case-management viewer rejects a 1.7 export
A contract exported at 1.7 with compressed xref returns 'document is damaged' in an old legal viewer. The blocker is object streams, so 1.4 is the fix.
Input: %PDF-1.7, compressed xref / object streams Target: PDF 1.4 Output: %PDF-1.4, plain xref table (object streams OFF) Result: opens in the legacy viewer, text still selectable
Reader documented as 'PDF 1.6 maximum'
The viewer parses fine but refuses anything flagged above 1.6. Here only the header is too new — target 1.6 and keep the compact structure.
Input: %PDF-1.7 Target: PDF 1.6 Output: %PDF-1.6, object streams kept ON Result: passes the reader's version check; smaller than a 1.4 rebuild
Stepping down until it opens
You don't know the reader's ceiling. Convert the original at each step until one loads — don't re-convert an already-converted file.
Try 1.6 → still fails (parse error) Try 1.5 → still fails (object streams still ON) Try 1.4 → opens ← object streams OFF did it Always start from the ORIGINAL each time, not the prior output.
Fillable form sent to an old reader
A 1.7 form downgraded to 1.4 opens — but the fields are gone, because the page-copy rebuild doesn't carry the AcroForm. Flatten first if the field values must remain visible.
Input: fillable AcroForm, %PDF-1.7 Target: PDF 1.4 Output: %PDF-1.4, opens in old reader, FIELDS DROPPED Fix: PDF Flatten (bake values into the page) → then convert to 1.4
Even 1.4 won't open it — content feature, not version
After downgrading to 1.4 the reader still fails. The cause is a content feature the old engine can't render, such as a JPEG2000 (JPXDecode) image, which version conversion doesn't touch.
Target 1.4 → still 'unsupported image' in the old reader
Diagnosis: a JPXDecode (JPEG2000) image is a 1.5 content feature.
Fix: rasterise the affected pages (PDF Compress Lossy) to
re-encode the image as JPEG, then convert to 1.4.Edge cases and what actually happens
Targeted 1.5 or 1.6 but the reader still can't parse it
Wrong target1.5 and 1.6 keep object streams and compressed cross-references on — they only change the header flag. If the reader is failing on the structure (a parse/damaged error), lowering to 1.5 or 1.6 won't help. Re-convert the original and target 1.4, the only setting that disables object streams.
Even 1.4 won't open in the old reader
Content featureOnce the header is 1.4 and object streams are off, the structural blockers are gone. A remaining failure points to a content feature the old engine can't render — most often a JPEG2000 (JPXDecode) image or advanced transparency. Re-encode the offending image (rasterise with PDF Compress (Lossy)) before converting.
Form fields vanished after downgrading
Dropped by designThe rebuild copies page-level objects, not the document AcroForm catalog, so interactive fields are not preserved at any target version. If the old reader's user needs to see the filled values, flatten with PDF Flatten first so the data becomes part of the page content.
Bookmarks and document JavaScript are gone
Dropped by designOutlines (bookmarks) and document-level JavaScript are catalog-level structures outside the copied pages, so they don't survive the rebuild. There's no option to keep them in this tool. Re-create bookmarks in a desktop editor if the old reader relies on them.
The source was password-protected
DecryptedThe converter reads past encryption and rebuilds the file with no security handler, so the downgraded output is unencrypted no matter the input password — and there's no password field on this tool. If the old system also needs the file protected, re-apply with PDF Password Protect after converting.
A digital signature broke
InvalidatedRe-serializing changes the bytes, which invalidates any existing signature (and the signature isn't carried through the rebuild). If the legacy system validates signatures, sign after converting with PDF Digital Signature.
Layered (optional-content) PDF flattens at 1.4
ExpectedOptional content groups (layers) are a 1.5 feature, so a layered document downgraded to 1.4 loses its layer structure. If the old reader needs layers and supports 1.5+, target 1.5 or 1.6 instead of 1.4.
File exceeds the tier size or page limit
400 limitPDF tools cap at 2 MB / 50 pages (free), 50 MB / 500 pages (Pro), and 500 MB / 2,000 pages (Pro+Media). Old-system documents can be large scans. Upgrade or shrink first with PDF Compress (Lossless).
Modern viewer opens it fine, so you assume the fix worked
Test in the right readerCurrent viewers open every supported version, so they'll happily open both the original and the downgraded file. Compatibility is only proven by opening the output in the specific old reader or embedded component that failed — test there, not in your everyday viewer.
Re-converting the already-downgraded file
Start from originalWhen stepping down versions, always re-run on the original. Converting an already-converted file just re-serializes again and refreshes metadata without adding value — and you lose the chance to compare against a clean source.
Frequently asked questions
How do I know which PDF version the old reader needs?
Check the reader's or vendor's documentation for its maximum supported version. If that's unavailable, work down empirically: try 1.6, then 1.5, then 1.4, each time converting the original file. 1.4 is the widest-compatibility floor because it's the only target that disables object streams and the compressed cross-reference — the structures that most often defeat a pre-2005 engine.
Should I always just pick 1.4 to be safe?
Only if you've confirmed lower versions are needed. 1.4 turns off object-stream compression, so the output can be slightly larger and it strips 1.5+ features like layers. If the reader only objects to the version flag (it parses the file but warns it's too new), pick the highest version it accepts — 1.5 or 1.6 — to keep the compact structure. Use 1.4 specifically when you're hitting parse/damaged errors.
Why didn't downgrading to 1.5 or 1.6 fix the 'damaged file' error?
Because 1.5 and 1.6 both keep object streams and a compressed cross-reference table — the tool only writes the plain xref/trailer form when you target 1.4. A reader that throws a parse/damaged error is choking on that compressed structure, so lowering to 1.5 or 1.6 changes only the header and not the thing that's failing. Re-convert and target 1.4.
Will the document look different in the old reader?
For standard text-and-image documents, no — this is a re-serialization, not a re-render, so the visible content is identical. The exception is optional-content layers (a 1.5 feature): downgrading a layered file to 1.4 loses the layer structure. Choose 1.5 or 1.6 if you need layers preserved and the reader supports them.
Is this the same as 'Save As earlier version' in Acrobat?
It serves the same purpose and produces a similar result — a lower-version header with the appropriate serialization — but it isn't byte-identical to Acrobat and doesn't perform Acrobat's content down-conversions (it won't re-encode a JPEG2000 image or down-convert transparency). For fixing the structural/version blocker it's equivalent; for content-feature conversion you'd still need a desktop preflight tool.
What happens to form fields, bookmarks, and signatures?
Interactive form fields (AcroForm), bookmarks/outlines, and document JavaScript are not carried through the page-copy rebuild, and any digital signature is invalidated and dropped. Page content, fonts, and images are preserved. If you need form values to remain visible, flatten the form first with PDF Flatten; sign after converting with PDF Digital Signature.
Does the downgraded file stay encrypted?
No. The converter reads past any encryption and rebuilds the file without a security handler, so the output is unencrypted regardless of the input — and there's no password field on this tool. Re-apply protection afterward with PDF Password Protect if the destination system requires it.
It still won't open even at 1.4 — what now?
At that point the version and structure are no longer the issue. Look for a content feature the old engine can't render: JPEG2000 (JPXDecode) images and certain transparency effects are common culprits. Rasterise the affected pages with PDF Compress (Lossy) to re-encode images as plain JPEG, then convert to 1.4.
Is my file uploaded to a server?
No. Reading and rewriting happen entirely in your browser via pdf-lib — the document never leaves your device. Only an anonymous usage counter is recorded when you're signed in (you can opt out). This matters because the documents trapped in old systems are often confidential legal, HR, or financial files.
Can I downgrade a batch of files for an old system migration?
The browser tool processes one file per run. For a migration batch, the converter is available through the @jadapps/runner on a paid tier: fetch GET /api/v1/tools/pdf-version-converter for the schema, pair the runner once, then POST each file with { "version": "1.4" } (or your chosen version) to 127.0.0.1:9789/v1/tools/pdf-version-converter/run. Files are processed locally — nothing is uploaded.
Which versions can I target?
Only 1.4, 1.5, 1.6, and 1.7. The dropdown defaults to 1.7. There is no 1.3 or 2.0 option. 1.4 is the lowest available and the widest-compatibility choice; if you genuinely need PDF 1.3 or earlier, a desktop preflight tool is required.
How large a PDF can I downgrade?
Free tier caps at 2 MB and 50 pages, Pro at 50 MB and 500 pages, Pro+Media at 500 MB and 2,000 pages, and Developer at 2 GB and 10,000 pages; beyond that you're bound by browser memory. Large old-system scans may need compressing first with PDF Compress (Lossless).
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.