Standards 10 min read 13 October 2026

PDF 2.0 (ISO 32000-2): What Changed and Why It Matters

PDF 2.0, published as ISO 32000-2:2017, was the first version of PDF developed entirely as an open ISO standard without Adobe as sole author. This guide explains every significant change: encryption, digital signatures, optional content, associated files, and deprecated features.

PDF 2.0, published as ISO 32000-2:2017, was a landmark release — the first version of PDF developed entirely through an open ISO process without Adobe as the sole author. Previous versions of PDF were Adobe specifications that were submitted to ISO; PDF 2.0 was written from scratch as a collaborative ISO standard by the PDF Association's working group. This change in governance had real consequences for the specification. Ambiguities that had accumulated over 20 years of single-vendor authorship were resolved. Deprecated features were explicitly labelled or removed. Security improvements that had been held back by compatibility concerns were finally incorporated. And new capabilities for archiving, structured data, and accessibility were formalised. This guide covers every significant change in PDF 2.0: what changed, why it changed, and what it means for PDF users, document authors, and software developers.

Encryption: RC4 gone, AES-256 strengthened

The most important security change in PDF 2.0 is the complete deprecation of RC4 encryption. All RC4-based encryption — including 40-bit RC4 (PDF 1.1–1.3) and 128-bit RC4 (PDF 1.4–1.5) — is deprecated in PDF 2.0 and should not be used in any new document. Additionally, PDF 2.0 introduces a new AES-256 encryption scheme (Revision 6) that addresses a significant weakness in the PDF 1.7 AES-256 implementation (Revision 5). Revision 5 had a flaw in its password verification mechanism that made offline brute-force attacks much faster than the underlying AES-256 key space would suggest. Revision 6 fixes this with a proper SHA-256-based key derivation function with iteration counts, making brute-force attacks against strong passwords impractical. For implementers: when producing encrypted PDFs, always use PDF 2.0 Revision 6. When reading, be aware that Revision 5 documents may have been produced with weak passwords. NIST SP 800-131A provides the underlying cryptographic guidance that informed these changes.

Digital signatures: LTV formalised, new requirements

PDF 2.0 incorporates long-term validation (LTV) of digital signatures directly into the core specification. Previously, LTV — the ability to verify a signature years after the signing certificate has expired — was defined in the ETSI PAdES extension standard rather than ISO 32000 itself. PDF 2.0 brings this into the core. Key signature changes: - **Document Security Store (DSS)** — A new dictionary in the document catalogue that stores certificates, CRLs (Certificate Revocation Lists), and OCSP responses needed for signature verification. This eliminates the need to contact external servers to verify an old signature. - **Signature appearance** — The specification now more clearly defines how signature appearances should be constructed, reducing inconsistency between viewers. - **Certification signatures** — The permissions granted by a certification signature (which operations are allowed without invalidating the certification) are more precisely specified. For organisations archiving signed documents — legal contracts, regulatory filings, financial records — the LTV formalisation in PDF 2.0 is significant. A PDF 2.0 signed document with embedded LTV data can be verified indefinitely without network access, which is essential for 10-30 year retention scenarios.

Associated files and the PDF/A-3 formalisation

PDF/A-3 (published in 2012 as an amendment to ISO 19005) introduced the concept of attaching files of any type to a PDF/A document. PDF 2.0 formalises this concept as **Associated Files** — a more structured mechanism for attaching related files with explicit relationship metadata. The Associated Files mechanism allows: - Attaching any file type to the document, a page, or even individual content elements (images, paragraphs) - Specifying the relationship of the attachment to the parent object (e.g., `Data` — the attachment is the data source for the parent content; `Source` — the attachment is a source file; `Supplement` — additional data) - Attaching multiple files with different relationships This is the mechanism underlying modern structured PDF workflows: - Factur-X/ZUGFeRD e-invoices — PDF/A-3 with attached CII XML invoice data - XBRL-embedded financial reports — PDF with attached XBRL data file - Engineering PDFs with attached CAD source files The /AF key in a content element or page dictionary lists its associated files; each entry is a file specification dictionary with a /AFRelationship key describing the semantic relationship.

Page-level output intents and colour management

PDF 1.x had document-level output intents — a single ICC colour profile declaring the target colour space for the entire document. PDF 2.0 adds **page-level output intents**, allowing different pages in the same document to target different output conditions. This is significant for: - **Mixed-media print production** — A PDF containing both coated (CMYK) and uncoated (CMYK) pages, each with the appropriate ICC profile - **Hybrid print/screen documents** — Different pages targeting sRGB (screen) vs FOGRA39 (coated offset print) - **Booklets with cover and interior** — Different paper stocks with different output intents per section For most users and most documents, this feature is irrelevant. For print production professionals, it enables previously impossible workflows where a single PDF could correctly target multiple output conditions. The output intent is now stored in the page dictionary's `/OutputIntents` array, mirroring the document-level structure.

Deprecated features: what was removed

PDF 2.0 explicitly deprecated several features that had been problematic: **RC4 encryption** — Deprecated entirely. All RC4 variants (40-bit, 128-bit) are non-conformant in a PDF 2.0 document. **XFA forms** — XFA (XML Forms Architecture) is deprecated. PDF 2.0 does not include XFA in the normative specification. New documents should use AcroForm. Existing XFA documents can still be opened by viewers that support it, but XFA is considered a legacy format. See XFA Form glossary. **Rich Media annotations (Flash)** — The Rich Media annotation type (used for embedding Flash content) is deprecated in PDF 2.0, consistent with Adobe's own Flash end-of-life. **3D annotations (U3D, PRC)** — While not removed, the specification notes that 3D annotation support is implementation-dependent and should not be relied upon for document portability. **Type 1 / Multiple Master fonts** — Deprecated as embedded font formats (though still supported for rendering compatibility). New documents should use OpenType or TrueType fonts. **PostScript XObjects** — Deprecated. These were a vestigial PostScript compatibility feature rarely used in modern PDFs. The deprecation of these features removes ambiguity: PDF 2.0 conforming writers should not produce documents using deprecated features, and PDF 2.0 conforming readers are not required to support them.

New and clarified features

Beyond security and deprecations, PDF 2.0 introduced several new capabilities and clarified numerous ambiguities: **Unassociated annotations** — New annotation type for document-level notes that are not associated with any specific page or location. Previously, all annotations needed a page reference. **Black point compensation** — Colour rendering intent for black point compensation is now formally specified. **User unit** — Each page can declare a user unit (the size of the default PDF user space unit). Previously this was an Adobe extension; PDF 2.0 formalises it. **Namespace dictionaries** — PDF 2.0 adds a namespace dictionary mechanism for structure element types, supporting the coexistence of elements from different namespaces (e.g., PDF standard structure types alongside custom or domain-specific types). This is important for PDF/UA-2 and the move toward more flexible tagging structures. **Many specification clarifications** — The PDF Association's working group spent years resolving interpretation ambiguities that had caused inconsistent implementation. PDF 2.0 resolves many of these, producing a more precisely specified standard. The PDF Association errata documents for PDF 1.7 give a sense of the scale of pre-existing ambiguity.

PDF 2.0 is a genuine improvement over PDF 1.7 — not a marketing rebrand. The AES-256 Revision 6 encryption fix alone is a significant security improvement. LTV formalisation, associated files, and the deprecation of XFA and RC4 make PDF 2.0 documents more secure, more interoperable, and more future-proof. Adoption has been gradual — most PDF tools added PDF 2.0 support between 2019–2022 — but the standard is now well-supported across Adobe, Foxit, open-source libraries, and cloud APIs.

Frequently asked questions

Is PDF 2.0 backwards compatible with PDF 1.7?

Mostly yes — a PDF 2.0 document can be opened by PDF 1.7 viewers, but PDF 2.0-specific features will be ignored or cause errors. The main incompatibilities are: AES-256 Revision 6 encryption (not supported in pre-PDF 2.0 viewers — the file will be unreadable to older software) and new PDF 2.0 constructs that old viewers do not understand. For maximum compatibility, use PDF 1.7 for documents intended for a broad audience; use PDF 2.0 specifically when you need the security or archiving features it provides.

When was PDF 2.0 published and who developed it?

PDF 2.0 was published as ISO 32000-2:2017 in July 2017. It was developed by the ISO TC 171/SC 2/WG 8 working group, with editorial leadership from the PDF Association. Unlike previous PDF specifications (which were Adobe documents submitted to ISO), PDF 2.0 was developed from the ground up as a collaborative ISO standard. A corrigendum (ISO 32000-2:2020) was published in 2020 to address errata.

Does my PDF tool support PDF 2.0?

Major PDF tools added PDF 2.0 support between 2018–2022. Adobe Acrobat has supported PDF 2.0 reading and writing since version DC (2017). Foxit PDF added PDF 2.0 support in 2018. The open-source libraries pypdf (Python), pdf-lib (JavaScript), iText 7 (Java), and QPDF all support PDF 2.0. To check if a specific PDF is PDF 2.0, open it in a hex editor and look for the header `%PDF-2.0`.

Should I convert my existing PDFs to PDF 2.0?

Only if you have a specific reason — for example, strengthening encryption from Revision 5 to Revision 6 AES-256, or adding LTV data for long-term signature validation. Converting "just to use PDF 2.0" is unnecessary. Most existing PDF 1.7 documents work perfectly well and do not need conversion. If you are producing new PDFs that require AES-256 Revision 6 encryption or LTV signatures, produce them as PDF 2.0 from the start using a compliant tool.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Protect PDF Sign PDF Edit PDF Open editor