Why teams choose NextPDF

SpecSpec: ISO 32000-2ISO 32000-2SpecSpec: ETSI EN 319 142-1ETSI EN 319 142-1

At a glance

Choosing a PDF engine is a small decision that quietly sets a lot of later ones. This page is the case for NextPDF, framed as the decision a team actually makes: stay in PHP or run a sidecar, own the code or rent a black box, produce real signatures or a checkbox, ship a prototype that survives production or one that has to be rewritten to get there.

Why this matters

The PDF you generate is rarely the end of the story. It gets signed, archived, emailed to a regulator, or opened years later by someone who was not in the room when you wrote the code. That makes a PDF engine an infrastructure choice, not a utility call. The wrong one shows up later as a signature a validator rejects, an archive a checker fails, or a vendor invoice you cannot leave because your documents only render through their service.

A team usually does not get to relitigate this decision. The engine they pick in week one is the engine on the critical path in year three. So the question worth answering honestly is not “can it make a PDF” — almost anything can — but “will this hold when the document becomes a legal or archival artifact.”

The short version

Teams choose NextPDF because it removes four separate risks at once:

• It is PHP-native. A PDF 2.0 engine that runs in your process, not a separate runtime you operate, scale, and secure beside your app.
• It is open by default. The core is Apache-2.0 — readable, forkable, vendorable. The advanced editions add capability; they never hold your documents hostage.
• Its signing is standards-grade. PAdES baseline profiles (SpecSpec: ETSI EN 319 142-1, §6ETSI EN 319 142-1 §6), not a homegrown signing scheme a European validator has never seen.
• It scales with the same code. The prototype you wrote on day one is the production code path. There is no “now port it to the real engine” step.

How NextPDF approaches it

Each of those four claims maps to a concrete property, and each is something a reviewer can check rather than take on faith.

PHP-native means no second runtime. NextPDF targets PDF 2.0 as defined in the format’s version-of-record (SpecSpec: ISO 32000-2, §6ISO 32000-2 §6), and it does so from inside your PHP process. There is no headless browser to keep alive, no microservice to deploy, no language boundary to marshal across. For a team whose stack is already PHP, the operational surface stays exactly as wide as it was. When a browser-grade renderer genuinely is the right tool, NextPDF can drive one — but it is a choice you make, not a dependency you inherit. That trade-off is the subject of the integration decision guide.

Open by default means no lock-in. The core engine is Apache-2.0. You can read every line that touches your bytes, vendor it into a private mirror, fork it if a release ever goes a direction you cannot follow, and keep shipping. A document produced by the core is a standard PDF that any conforming reader opens — it is not a proprietary container that only round-trips through one vendor’s service. The commercial editions are additive: they unlock capabilities such as hardware-backed signing and high-volume features, but the documents they produce remain ordinary, standards-conforming PDFs you fully own.

Standards-grade signing means a signature that survives review. This is where a “good enough” PDF library quietly becomes a liability. A signature that a validator does not recognise is, for the purpose that mattered, not a signature. NextPDF targets the PAdES baseline progression — B-B, B-T, B-LT, B-LTA — defined by ETSI, the levels a European validator and an auditor expect to see. The boundary is a tiered one: the Apache-2.0 core ships a software CMS/PAdES signer for the B-B and B-T levels using a local or supplied key, while the long-term-validation levels (B-LT, B-LTA) and HSM- or cloud-KMS-backed keys are advanced-edition capabilities. PAdES is the ETSI signature profile for PDF; eIDAS — the EU regulation (SpecSpec: Regulation (EU) No 910/2014 (eIDAS), Art. 25Regulation (EU) No 910/2014 (eIDAS) Art. 25) — is what gives an electronic signature its legal standing, and PAdES is the PDF realisation an eIDAS obligation resolves to, which is exactly why the engine targets the profile family rather than a near-miss. The PAdES baseline profiles page walks the progression and how to pick the level your obligation actually needs.

1. Stay in your stackA PHP-native PDF 2.0 engine runs in-process — no second runtime to deploy, scale, or secure.
2. Own what you shipApache-2.0 core: readable, forkable, vendorable. The documents are standard PDFs you keep, not a proprietary container.
3. Sign for realPAdES baseline profiles (ETSI EN 319 142-1), the levels a validator and an auditor recognise — not a homegrown scheme.
4. Grow without a rewriteThe prototype is the production path. Fail-fast typed inputs catch mistakes in development, where they are cheap.

The decision a team faces when adopting a PDF engine, and the NextPDF property that resolves each step: stay native rather than operate a sidecar; own the code under Apache-2.0 rather than rent a black box; emit a recognised PAdES profile rather than a bespoke signature; and keep the same code path from prototype to production.

Prototype to production means no rewrite. The fourth risk is the quietest: a tool that demos beautifully and then has to be replaced to go live. NextPDF is built so the first program you write is the same program you operate. Inputs are strictly typed and validated at the edge, so the failure modes you will see in production are the ones you already saw in development — named, at the call site, before a byte is written. That stance is the subject of the design philosophy and an API that refuses to guess; here it matters because it is what lets the same code path carry a team from a weekend spike to a regulated workload.

Human-factors note:Human-factors note

Adopting an engine is a team decision, and the cost a team most often underestimates is not the first document — it is the tenth change to it, made by someone who did not write the first nine. Strict types and fail-fast inputs are a kindness to that future maintainer: the engine refuses an ambiguous call instead of guessing and shipping a wrong document that nobody notices until a validator does. The friction lands in code review, where it is cheap, rather than in a signed artifact, where it is not.

Practical example

The shape of “prototype to production with the same code” is easiest to see at the call site. The program a team writes to evaluate the engine is, line for line, the program that runs in production — only the signing material changes.

<?php

declare(strict_types=1);

use NextPDF\Contracts\Orientation;
use NextPDF\Contracts\OutputDestination;
use NextPDF\Core\Document;
use NextPDF\Signature\SignatureLevel;
use NextPDF\ValueObjects\PageSize;

$document = Document::createStandalone();
$document->setTitle('Service Agreement');

// Typed page geometry and an enum orientation — intent is explicit,
// so a typo is a type error in development, not a silent default in production.
$document->addPage(PageSize::a4(), Orientation::Portrait);
$document->setFont('helvetica', 'B', 16);
$document->cell(0, 12, 'Service Agreement', newLine: true);

// The signature level is a recognised PAdES baseline profile, named as an
// enum case — never a string the engine has to interpret. B-T is a core
// software-signing level; the long-term levels (B-LT, B-LTA) are an
// advanced-edition capability selected the same way.
$document->setSignature(certInfo: $certInfo, level: SignatureLevel::PAdES_B_T);

// The output destination is stated, not inferred from whether a filename
// was passed. The same call shape serves a spike and a production endpoint.
$bytes = $document->output(dest: OutputDestination::String);

Nothing in this program changes between the prototype and the deployment. The team swaps real signing material for the placeholder and points the output at a response instead of a buffer. The engine, the API, and the failure modes are identical in both places — which is the entire point.

Common misconception

The frequent objection is “open-source core means the real product is paywalled, so the free part is a teaser.” That gets the relationship backwards. The core is a production PDF 2.0 engine under Apache-2.0 — document generation, standards- conforming output, and software CMS/PAdES signing at the B-B and B-T levels; teams run it in production unmodified. The advanced editions add specialised capability — long-term-validation signing (B-LT, B-LTA), HSM- and cloud-KMS- backed keys, scale features — for the teams that need them. The test is simple and verifiable: a document the core produces is a standard PDF that opens in any conforming reader, with no dependency on a NextPDF service to read it back. There is no hostage to ransom.

A second misconception is that “PHP-native” means “less capable than a browser engine.” It means different, and the cases where a browser-grade renderer is the better fit are catalogued in when not to use NextPDF.

Limits and boundaries

NextPDF is the right tool for programmatic, standards-grade document generation in a PHP stack. The cases where a different category of tool fits better are catalogued in when not to use NextPDF.

Hardware-backed (HSM) signing — edition availability

Edition	Availability
Core	○Not in this edition — software signing only (B-B, B-T).
Pro	○Available — HSM and qualified-device signing.
Enterprise	○Available — HSM and qualified-device signing.

Two boundaries deserve emphasis. First, signing capability is tiered: the Apache-2.0 core provides software CMS/PAdES signing at the B-B and B-T levels with a local or supplied key, while the long-term-validation levels (B-LT, B-LTA) and hardware-backed keys through an HSM, qualified device, or cloud KMS are advanced-edition capabilities. Second, conformance is decided by an independent checker, never by the producer. PAdES is the ETSI signature profile for PDF; PDF/A-4 (SpecSpec: ISO 19005-4, §6ISO 19005-4 §6), defined by ISO 19005-4, is a separate archival conformance level. NextPDF can target each, but targeting a profile is not a guarantee of conformance: the authoritative verdict comes from a PDF/A validator or a signature validator, not from the engine that wrote the file. Treat the engine as the tool that gets you to “should pass,” and the checker as the tool that says “does pass.”

Related docs

• The integration decision guide — once you have chosen NextPDF, which package and renderer fit your use case.
• When not to use NextPDF — the boundary on this case; the document problems that fit a different tool.
• PAdES baseline profiles — how the B-B → B-LTA progression works and which level your obligation needs.
• The company behind NextPDF — who maintains the engine a team is choosing to depend on.

Glossary

• PDF 2.0 — the current version of the PDF format, specified in ISO 32000-2. NextPDF targets it as the version-of-record, so its output is measured against the current ISO standard rather than a vendor dialect.
• PAdES — PDF Advanced Electronic Signatures, the ETSI profile family (EN 319 142-1) for signing PDFs. Its baseline levels — B-B, B-T, B-LT, B-LTA — are what a European validator and an auditor expect to see.
• eIDAS — Regulation (EU) No 910/2014, the EU framework that gives electronic and qualified signatures their legal standing; PAdES is the PDF realisation an eIDAS obligation resolves to.
• PDF/A — the archival conformance family (here, PDF/A-4 under ISO 19005-4) for documents that must remain self-contained and readable for the long term.
• Apache-2.0 — the permissive open-source licence of the NextPDF core: you may use, modify, vendor, and redistribute the engine, with no obligation to open your own application.
• No lock-in — the property that the documents an engine produces are standard, vendor-neutral artifacts you fully own, readable without any dependency on the producer’s service.