PDF Versions Explained: From 1.4 to 1.7 to PDF 2.0
PDF began in 1993 as a proprietary Adobe format, and for its first fifteen years the version number simply tracked which release of Acrobat had introduced a feature. That changed in 2008, when PDF 1.7 was adopted as ISO 32000-1 and the format became a genuinely open standard maintained through committee. PDF 2.0 arrived as ISO 32000-2 in 2017 with a revision published in 2020. The numbers in a file header are therefore a history of capabilities, and reading them tells you what a file is allowed to contain.
A few versions matter more than the rest. PDF 1.4 introduced the transparency model, meaning real alpha blending, soft masks and blend modes rather than the earlier all-or-nothing painting, and it also brought in the JBIG2 filter for bilevel scans. PDF 1.5 added object streams and cross-reference streams, which let a writer compress many small objects together and shrink files noticeably. Encryption strengthened in stages, moving from the early RC4 schemes to AES-128 in PDF 1.6, with AES-256 becoming the standardised approach in PDF 2.0. Each step made the format more capable and slightly less universally readable.
There is a subtlety worth knowing. The version appears in the header line at the top of the file, but the document catalogue can also carry a Version entry that overrides it, which is how an incremental update can promote a file without rewriting the first bytes. Readers are also deliberately forgiving. The format was designed so an unknown dictionary key or an unrecognised optional feature can be ignored rather than treated as a fatal error, which is why most modern files still open in older software with only cosmetic differences.
Forgiveness has limits, and encryption is where it ends. If a file is protected with an algorithm the reader does not implement, there is no graceful degradation available: the reader cannot decrypt the content streams at all, so it refuses the document outright rather than showing a slightly wrong page. New compression filters can produce a similar hard stop for the streams that use them. This is the practical reason a colleague on ancient software reports that your file is invalid while it opens perfectly for everyone else.
The compatibility advice that follows is unglamorous but effective. Unless you need a specific modern feature, let your export tool write a widely supported version and do not chase the newest number for its own sake. If a document is going to an unknown audience, such as a regulator, a printer or a large organisation with locked-down software, test it in a second reader before sending. And keep encryption in mind specifically: the protect tool on PdfWill uses AES-256, which is the right choice for real confidentiality and does expect a reasonably current reader on the other end.