Why PDF 2.0, and why now

Most PHP applications still generate PDFs the way they did a decade ago: a static, untagged file based on the PDF 1.x era. It opens, it prints, and it carries no idea of its own structure. For a long time that was enough. It is not enough any more.

What PDF 2.0 changes

ISO 32000-2 — PDF 2.0 — is the current standard, and it frames how the modern document world works: tagged structure for accessibility (PDF/UA-2), archival profiles (PDF/A-4), signature containers (PAdES), and colour management done properly (ICC v4). NextPDF is built around the PDF 2.0 model from the core out, rather than shimming it over an older engine.

That matters because the obligations attached to documents have changed:

• Accessibility is now table stakes. A document that is just pixels excludes assistive technology and, increasingly, fails procurement. PDF/UA-2 tagging carries the document’s semantics so a screen reader can navigate it.
• Signatures have to last. A baseline signature is easy; a signature that still verifies in ten years (PAdES B-LTA, with timestamps and revocation data) is a different engineering problem.
• Archival and e-invoicing are regulated. PDF/A-4 and the ZUGFeRD / Factur-X invoice profiles are common requirements in regulated archival and e-invoicing workflows — often what lets a document clear procurement or tax systems where they apply.

Built for what comes next

PDF 2.0 also makes documents legible to machines, not just people. NextPDF exposes deterministic PDF tools to AI systems over a typed contract (MCP, REST, and gRPC), so an agent can create, analyse, sign, and validate documents without the guesswork of pixel OCR.

A PDF engine written for the previous decade can paper over some of this. It cannot give you the foundation. NextPDF starts from the standard, so accessibility, signatures, and archival profiles are part of the architecture from the outset — not features you bolt on later.