Open almost any PDF in a hex editor and the first line tells you
something most people never look at: %PDF-1.4, %PDF-1.7,
%PDF-2.0. That number is the PDF version — a tiny header field
that decides whether some legacy intake portal accepts your file or
rejects it before a human ever sees it.
Most of the time the version doesn't matter. The file opens, the content renders, nobody cares. But every so often you'll hit a system — a court filing portal, an insurance claims uploader, an old print RIP, a corporate document management system — that strictly checks the header and refuses anything outside a narrow window. That's when PDF versions become unavoidable.
This guide covers what each version actually changes, which one to target, and when to reach for the Change PDF Version tool to rewrite the header.
What a PDF version actually is
The first bytes of every PDF file are a comment line like:
%PDF-1.7
That number declares which generation of the PDF specification the file claims to conform to. Anything between version 1.0 (1993) and 2.0 (2020) is in active use somewhere. The version tells consumers:
- Which features can appear inside. Transparency, JPEG2000 images, AES-256 encryption, attached files — each was introduced in a specific version. A consumer parsing a 1.3 file knows it won't encounter any of those.
- Which behavior to expect from features that exist across versions. Encryption, for example, changed algorithms multiple times. A 1.4 file uses RC4 40-bit; a 1.7 file might use AES-128; a 2.0 file might use AES-256.
- Whether to accept the file at all. Strict systems use the version as a fast filter — if you require ISO 32000-1, anything below 1.7 gets rejected at the door.
In practice most modern readers (Acrobat, Preview, browsers, mobile viewers) ignore the version and just try to render whatever they find. The strict checks happen at intake systems, not at viewing.
The versions in active use
PDF 1.3 (2000, Acrobat 4). The baseline a lot of legacy intake portals still target. No transparency, no smart layers, no modern encryption. Files are small because half the modern features are absent. You'll occasionally see this required by government mainframes or banking pipelines that haven't moved.
PDF 1.4 (2001, Acrobat 5). Added transparency (the headline change — semi-transparent overlays, blending modes), JBIG2 image compression, and tagged PDF for accessibility. Probably the most common "lowest common denominator" version still requested by older print workflows and PDF/A-1 archival.
PDF 1.5 (2003, Acrobat 6). Added object streams and cross-reference streams (the two changes that let modern PDFs get smaller for the same content), JPEG2000 images, and improved form handling. Most PDFs created by modern tools are at least 1.5 under the hood, even if they declare 1.7 in the header.
PDF 1.6 (2005, Acrobat 7). Added 3D content (CAD-style 3D models embedded in pages), AES-128 encryption, and OpenType font support. The features are niche; 1.6 mostly exists as a stepping stone to 1.7.
PDF 1.7 (2008, ISO 32000-1). The first version to become an ISO international standard. Everything from 1.6 plus richer form fields, optional content groups (formal layers), and a tighter specification — fewer ambiguities for implementers. This is the de facto default for modern PDF production. If you don't have a reason to pick something else, 1.7 is the safe choice.
PDF 2.0 (2017, revised 2020, ISO 32000-2). The first major revision since 1.7. AES-256 encryption is now the default, digital signatures got modernized, the spec was cleaned of legacy ambiguity, and several deprecated features were formally removed. Adoption is steady but not universal — some older readers still choke on 2.0 files.
When to change the version
A handful of concrete scenarios:
- An intake portal rejects your file with a "PDF version not supported" error. The portal is doing a strict version-header check. Downgrade to the version it asks for (usually 1.4 or 1.7) and resubmit.
- A legacy print RIP or document management system can't read the file. Older RIPs and DMS deployments often max out at 1.4 or 1.5. The content might use only basic features, but the header bumps the version up to 1.7 and the RIP refuses to parse it. Downgrading the header lets it through.
- You're submitting to a workflow that requires ISO 32000-1. That means PDF 1.7 specifically. Files declared as 1.4 or 1.5 get rejected even if the content would have been valid 1.7.
- You're producing PDFs for long-term storage but not full PDF/A. A common compromise is "PDF 1.7 with embedded fonts, no encryption" — preservation-grade but not the full PDF/A conformance overhead. The Change PDF Version tool handles the header rewrite; embed fonts at export time in your authoring application.
The pattern is always the same: a downstream consumer is checking the version field and refusing to proceed if it's not what they want. The fix is to rewrite the version field. The contents of the file don't need to change — the consumer's check is on the header, not on what's inside.
Downgrade vs upgrade: what actually happens
Downgrading the version (say, 1.7 → 1.4) is the more common
direction and the more interesting one technically. The Change PDF
Version tool uses a lossless header rewrite — qpdf's
--force-version flag, which only updates the version marker. It
does not:
- Re-encode page content
- Recompress images
- Remove transparency, layers, or other "newer" features
That means if your 1.7 file contains transparency (a 1.4-incompatible feature), the downgraded file still contains that transparency — it just declares 1.4 in the header. Strictly speaking, the result is a non-conformant 1.4 file. In practice:
- Modern viewers (Acrobat, Preview, browsers) ignore the discrepancy and render everything.
- Legacy strict consumers that wanted 1.4 specifically accept the file because the header passes their check. They typically don't validate the body against the version they asked for.
This is the right behavior for the common case (passing intake checks) and a wrong behavior for the rare case where the consumer actually parses every object and crashes on a 1.4-illegal feature. If you're hitting that rare case, you need a true downgrade — re-rendering the PDF without the newer features — and that's a different (lossy) operation, not a header rewrite.
Upgrading the version (1.4 → 2.0, say) is mostly cosmetic. The file doesn't suddenly gain transparency or modern encryption just because you bumped the header. Upgrading is useful when a downstream system requires the higher version number but the file content is fine either way — exactly the same shape as the downgrade case, in reverse.
How to change a PDF's version
Use the Change PDF Version tool:
- Upload your PDF.
- Pick the target version (1.3, 1.4, 1.5, 1.6, 1.7, or 2.0).
- Download the result. The filename is prefixed with the version so you can keep multiple variants without confusion.
The operation is fast — the tool rewrites the header without touching page content, so a 100-page document takes the same time as a 1-page document. No re-encoding, no quality loss, no metadata stripping.
If your goal is archival, not just "passing a version check", PDF/A is the right format rather than a plain version downgrade. PDF/A enforces a constrained subset of features and bakes in font and color-profile embedding — it's a different kind of "downgrade", one that actually changes the file's content.
Common questions
Which PDF version should I produce by default?
1.7 unless you have a specific reason to pick something else. It's the ISO 32000-1 standard, every modern reader handles it cleanly, and it's wide enough to support the features most documents use. 2.0 is fine for new workflows but adds friction with older consumers.
Will changing the version reduce my file size?
No. The Change PDF Version tool only rewrites the header. The page content, fonts, images, and compression all stay exactly as they were. If you want a smaller file, compress the PDF separately. Compression and version-change are independent operations — you can do both, in either order.
Does changing the version invalidate digital signatures?
Yes. A certificate-based digital signature cryptographically covers a byte range of the file. Rewriting the header changes those bytes, which breaks the signature. If a document is signed and you need to change its version, re-sign it after the version change. Visual signature stamps (drawn or typed signatures with no cryptographic metadata) are unaffected.
Can I change the version of a password-protected PDF?
No. Encrypted PDFs need to be opened with the password before any structural change can be made. Use Unlock PDF first (you'll need the password), then change the version, then re-apply protection with Protect PDF if needed.
How do I check what version my PDF currently has?
Open the file in Acrobat → File → Properties → "PDF Version"
field. In Preview on Mac, Tools → Show Inspector → General.
On Linux, pdfinfo file.pdf | grep "PDF version". Or open the
file in a text editor and look at the first line: %PDF-1.7 means
version 1.7.
Is there a "best" PDF version for accessibility?
1.5 or higher for tagged PDF support. Accessibility tagging (the structure tree that screen readers use) was introduced in 1.4 and refined in 1.5, so anything 1.5+ is fine. The version itself doesn't make a document accessible — that requires actual tagging during authoring or post-processing — but 1.4 is the oldest version that can carry a tagged structure at all.
What happens if I downgrade a 2.0 file with AES-256 encryption to 1.4?
The file becomes structurally weird: a 1.4 file isn't supposed to contain AES-256 encryption. Most viewers will refuse to open it, because the encryption dictionary won't match what they expect from a 1.4 file. Encryption is one of the few places where a version downgrade can produce a file that genuinely doesn't work. If you need to downgrade an encrypted file, unlock it first, downgrade, then re-encrypt with an algorithm appropriate to the new version (RC4 for 1.4, AES-128 for 1.6, AES-256 for 1.7+).
Wrap-up
For most workflows, the PDF version is invisible. You produce a 1.7 file, the recipient opens it, nobody thinks about the header. The moment a downstream system rejects the file, the version becomes the variable to change.
Three rules cover almost every case:
- Produce 1.7 by default. It's the modern ISO standard and the widest compatibility target.
- Downgrade only to satisfy a strict intake check. Don't downgrade preemptively — older versions strip nothing useful from your file's actual contents (the tool only rewrites the header), but they signal to consumers that they should expect fewer features.
- Upgrade only when a system requires a higher version number. Upgrading is cosmetic; it doesn't add capability, it just makes the header read higher.
If you find yourself frequently changing versions for the same workflow, build the version target into your export step rather than rewriting after the fact. The change-version tool is for fixing existing files, not as a habitual production step.