Skip to content

PDF 2.0: what changed

Evidence: Standard-backed

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.

“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.

  • 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.

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.

  1. Step 1 of 3: ISO 32000-1 PDF 1.7 — the Adobe-authored base, adopted by ISO
  2. Step 2 of 3: ISO 32000-2 PDF 2.0 — ISO-owned consolidation, tightening, and additions
  3. 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.

The version statement is normative. Spec: ISO 32000-2, §7.5.2 states that a processor writing a conforming file shall identify the version — either in the header or as the catalog /Version entry — as 2.0, and that the header is %PDF-1.n or %PDF-2.n followed by a single end-of-line marker. Spec: ISO 32000-2, §7.7.2 adds that the catalog /Version overrides an earlier header version, which is exactly what makes an incremental version bump possible. Evidence: Standard-backed

That 2.0 is a consolidation, not a rewrite, shows in what it keeps: the cross-reference stream (/Type /XRef) is the same mechanism introduced in PDF 1.5 and carried forward as the 2.0 default ( Spec: ISO 32000-2, §7.5.8 ). The indirect object, trailer, and startxref structure is unchanged from the previous page’s description.

The changes that matter are removals and tightenings. The standard records that six standard structure elements present in the PDF 1.7 standard structure namespace are not part of the PDF 2.0 namespace — Art, BlockQuote, TOC, Reference, BibEntry, and Code ( Spec: ISO 32000-2, Annex L.3 , with the namespace differences defined per Spec: ISO 32000-2, §14.8.6 ). It also tightens the fourteen standard Type 1 fonts: where 1.0–1.7 allowed their dictionaries to omit metrics entries, 2.0 closes that allowance ( Spec: ISO 32000-2, §9.6.2.1 ). And it revises the predefined CJK character collections. For example, Adobe-Korea1 is deprecated in 2.0. Adobe-KR is added. None of these change how an existing page looks. All of them can change whether it conforms.

CategoryExamples (2.0 vs 1.7)Does it change appearance?Why it matters
UnchangedIndirect objects, trailer, startxref/%%EOF, xref streams2.0 is the same object model; most tooling carries over
AddedRicher associated-files / document-part structure; AES-256-GCM encryption (ISO/TS 32003)NoNew capability you opt into; ignored safely by older readers
TightenedStandard-14 fonts expected embedded; metrics no longer omissibleNoA valid 1.7 file can be a non-conformant 2.0 file
RemovedSix 1.7-namespace structure elements (Art, BlockQuote, TOC, Reference, BibEntry, Code); deprecated CJK collections (for example, Adobe-Korea1)NoSilent: nothing visible signals the lost conformance

The PDF 2.0 changes that matter are overwhelmingly invisible: additions you opt into, and tightenings/removals that change conformance without changing a single rendered pixel.

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.

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.

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.

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.

  • 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.