PDF 2.0: what changed

At a glance

PDF 2.0 is ISO 32000-2. It is the first PDF specification owned wholly by ISO rather than by Adobe. It is mostly a consolidation and cleanup of 1.7 rather than a dramatic reinvention. This page covers what actually changed, which of those changes you will feel in practice, and how NextPDF targets the 2.0 baseline by default while still being able to write older file structure when a profile demands it.

Why this matters

“PDF 2.0” sounds like it should be a different format. It is not. A 2.0 file uses the same object model, xref, and trailer as 1.7, which makes the real changes easy to underestimate. The changes that cause problems are not the headline features. They are the tightenings: rules that were optional in 1.7 and are now expected, and features that were quietly removed. A document that was a perfectly valid 1.7 file can be a non-conformant 2.0 one without a single visible difference.

The other reason this matters is direction. NextPDF is a PDF 2.0 engine. Once you know what 2.0 expects, and where it deliberately differs from 1.7, you can reason about why the engine refuses some things, embeds fonts more strictly, and defaults to a cross-reference stream instead of a table.

The short version

PDF 2.0 = ISO 32000-2, ISO-owned, building on (not replacing) 1.7.
The header becomes %PDF-2.0; a conforming writer states the version as 2.0 in the header or the catalog /Version.
Most of the file structure is unchanged — same indirect objects, same trailer, same startxref/%%EOF discipline.
The cross-reference stream is the natural 2.0 default; the classic 20-byte table is still legal and still required by some PDF/A profiles.
2.0 adds things (for example, richer associated-files and document-part structure, stronger encryption via the AES-256-GCM extension) and removes things (some structure tags; tightened font-embedding expectations; deprecated CJK character collections).
NextPDF targets 2.0 by default and can serialize 1.7/1.4 structure when a conformance profile requires it.

How NextPDF approaches it

The version is a decision, expressed in one place: the serialization strategy.

Pdf20StreamStrategy (src/Writer/Pdf20StreamStrategy.php) writes the %PDF-2.0 header, reports /2.0 as the catalog version, and emits a compressed cross-reference stream. It also carries the 2.0 font tightening directly. Under the 2.0 profile it can enforce a non-embedded standard Type 1 font, rather than merely warn about it, because the standard now expects those fonts embedded. The two table strategies (Pdf17TableStrategy, Pdf14TableStrategy) exist precisely because some profiles need the older shape. PDF/A-2/-3 mandate the traditional cross-reference table, and PDF/A-1 additionally forbids object and cross-reference streams. All three strategies implement the one PdfSerializationStrategy interface, so the writer is identical above the seam. Only the trailer/xref shape changes.

Stronger encryption is wired the same deliberate way. PdfXrefWriter (src/Writer/PdfXrefWriter.php) propagates an AES-256-GCM opt-in (the ISO/TS 32003 extension to 2.0) into the encryption dictionary so the emitted handler version and cipher-mode entries match the bytes actually produced. The engine does not advertise one cipher and write another.

The overall design is this. 2.0 is the default. Older structure is reachable on purpose, never by accident. And where 2.0 tightens a rule, NextPDF can hold the tightened line rather than silently relax it.

Step 1 of 3: ISO 32000-1 PDF 1.7 — the Adobe-authored base, adopted by ISO
Step 2 of 3: ISO 32000-2 PDF 2.0 — ISO-owned consolidation, tightening, and additions
Step 3 of 3: ISO/TS 32003 AES-256-GCM (AESV4) — an encryption extension to PDF 2.0

The PDF version lineage NextPDF reasons about: PDF 1.7 became the ISO base, ISO 32000-2 is PDF 2.0, and ISO/TS 32003 extends 2.0 with AES-256-GCM encryption.

Practical example

The only visible difference between a 2.0 file and a 1.7 file is often two lines — the header and the catalog version — even though the conformance rules behind them differ substantially.

%PDF-2.0                                  % was %PDF-1.7
...
1 0 obj
<< /Type /Catalog /Version /2.0           % catalog states 2.0; overrides header if later
   /Pages 2 0 R >>
endobj
...
% Cross-reference STREAM is the 2.0 default (was often a 20-byte table)
99 0 obj
<< /Type /XRef /Size 100 /W [1 2 2] /Filter /FlateDecode /Root 1 0 R >>
stream
<binary xref entries>
endstream
endobj
startxref
12345
%%EOF

A reader sees %PDF-2.0 and a /Version /2.0. What it does not see — and what a conformance checker does — is that this file is now expected to embed its standard fonts and must not use the structure tags 2.0 removed. The bytes that differ are few. The rules that differ are not.

Common misconception

The trap is “we output PDF 2.0, so we are more conformant than before.” Writing %PDF-2.0 is a claim, not a guarantee. A file can carry the 2.0 header and still violate 2.0 — by referencing an unembedded standard font, or by using a feature 2.0 removed — in exactly the way that was tolerated under 1.7. The version marker raises the bar the file is measured against. It does not lift the file over it. The mirror-image mistake is assuming a 1.7 file works as 2.0 by changing the header: usually it renders identically and fails conformance, because the tightenings are real even though they are invisible.

Limits and boundaries

Targeting the 2.0 baseline means NextPDF defaults to 2.0 file structure and can hold 2.0’s tightened rules. It does not mean every optional 2.0 feature is implemented, nor that emitting a 2.0 header certifies a document against PDF/A, PDF/UA, or any other profile. Those are separate, stricter conformance targets layered on top of the base specification, each with its own validation.

This page is a practical orientation to the version differences, not an exhaustive change log of ISO 32000-2 versus 32000-1. Where a specific 2.0 feature or deprecation governs engine behavior, that behavior is anchored to its own clause. This page maps the landscape rather than enumerating every clause-level delta.

Mini-FAQ

Is PDF 2.0 backward compatible with 1.7 readers? Largely, for the unchanged structure. New 2.0 features are generally designed so an older reader can ignore what it does not understand. But a 2.0-only feature will not be honored by a 1.7 reader.

Does the header or the catalog /Version win? The catalog /Version takes precedence when it names a later version than the header. This is what lets an incremental update raise a file’s version without rewriting the header.

Why does NextPDF default to a cross-reference stream, not a table? The cross-reference stream is the natural PDF 2.0 mechanism — compact and able to index compressed objects. The 20-byte table is still written when a profile (notably some PDF/A levels) requires it.

What a PDF actually is — the object model and xref that PDF 2.0 keeps from 1.7.
The standards landscape — where ISO 32000-2 sits among the standards NextPDF tracks and how a clause becomes behavior.
Fonts: the hard part — the font-embedding tightening is one of the 2.0 changes you actually feel.

Glossary

PDF 2.0 — the PDF specification standardized as ISO 32000-2, the first edition owned by ISO rather than Adobe.
ISO 32000-1 — the ISO standardization of Adobe’s PDF 1.7; the base PDF 2.0 builds on.
ISO/TS 32003 — a technical specification extending PDF 2.0 with AES-256-GCM (AESV4) encryption.
Catalog /Version — the document catalog entry stating the PDF version; overrides the header when it names a later version.
Cross-reference stream — the PDF 1.5+ / 2.0 cross-reference mechanism (/Type /XRef); NextPDF’s default, with the classic table still available for older profiles.
Tightening — a rule that was optional or permitted in 1.7 and is expected or required in 2.0, changing conformance without changing appearance.