When not to use NextPDF

SpecSpec: ISO/IEC 25010, §3.26ISO/IEC 25010 §3.26SpecSpec: ISO 24495-1ISO 24495-1

At a glance

This page covers where NextPDF is not the right tool, and what kind of tool fits instead. It names the non-fit cases plainly, so you can rule the engine out quickly when it deserves to be ruled out.

Why this matters

The most expensive integration is the one you should not have started. Tool selection is cheap to get right at the evaluation stage. It is very costly to correct once the contracts are signed and the pipeline is in production.

A good engine helps you decide that early. Software-quality guidance calls this appropriateness recognizability: the ability to judge whether a product fits your need from its documentation and first impressions (SpecSpec: ISO/IEC 25010, §3.26ISO/IEC 25010 §3.26). A page that only ever says yes fails that test on purpose. This one says no where no is the right answer.

The short version

Reach for something other than NextPDF when:

• You need pixel-faithful rendering of arbitrary modern web pages — full CSS, web fonts, JavaScript-driven layout. That is a browser’s job.
• You need to OCR or reconstruct scanned or image-only PDFs into structured text. That is an OCR/document-understanding problem, not a generation one.
• You need a conformance verdict (PDF/A, PDF/UA, PAdES) as the authoritative answer. NextPDF produces structure intended to conform; an independent validator decides whether it did.
• You need heavy interactive editing or redaction of third-party PDFs as the core workload, rather than producing or inspecting them.
• You are on a runtime older than the supported PHP floor and cannot use the backport path.

In each case the issue is category, not quality: a different kind of tool is the right answer.

How NextPDF approaches it

NextPDF is a PHP engine for producing PDF 2.0 documents, and for inspecting them for structural facts. Its design — explicit intent, fail-fast inputs, in-process and deterministic — is tuned for that job. The boundaries are where a problem is a fundamentally different shape.

The table maps each non-fit case to why it is the wrong shape and what category of tool fits. No product is named; the point is the category.

If your problem is…	Why NextPDF is the wrong shape	What fits instead
Pixel-faithful rendering of arbitrary modern web pages	The in-process HTML/CSS engine targets a defined, documented subset for predictable, deterministic output — not the entire evolving web platform with scripting	A real browser engine (a headless-browser renderer), driven via the ecosystem’s browser bridge
Turning scanned or image-only PDFs into structured text	NextPDF does not perform OCR or document understanding; it generates and structurally inspects, it does not interpret pixels into meaning	A dedicated OCR / document-understanding pipeline; feed its output to NextPDF if you then need to produce a PDF
An authoritative conformance verdict	In-process checks are necessary, not sufficient — by design they report structural facts, not a pass/fail ruling	An independent validator (for example a recognized PDF/A or accessibility checker) as the gate
Heavy interactive editing / redaction of arbitrary PDFs as the core job	The engine optimizes for generation and structural inspection, not as a general round-trip editor of untrusted third-party files	A tool category built for editing/redaction workflows; use NextPDF for the produce/inspect parts
A runtime below the supported PHP floor	The engine builds on modern PHP language features deliberately	The documented backport path where applicable; otherwise a different toolchain

The engine’s in-process conformance checks state their own scope in their output: they are necessary, not sufficient — a clean result “does not establish ISO conformance”, and the verdict “belongs to an independent validator”. Its quick PDF inspector reports the same scope: it is “a fast structural triage, not a validator … it does not verify signatures, decrypt content, or assert conformance. Treat the result as routing input, not a trust verdict.”

Some boundaries are not fixed lines but edition boundaries. Archival (PDF/A) production, for instance, is a higher-tier capability rather than a missing one. The engine surfaces an actionable upgrade path, not a refusal:

PDF/A archival production — edition availability

Edition	Availability
Core	○ Not in Core — calling the archival API returns an actionable message naming the package that enables it, rather than failing obscurely. Plain PDF 2.0 output is fully available.
Pro	○ Available — PDF/A archival conformance production is an Enterprise-tier capability.
Enterprise	○ Available — included with the higher tier.

So “NextPDF cannot do archival” is the wrong way to read it on Core. It can, in the right edition, and it tells you so explicitly instead of guessing or failing silently. The genuine boundary is still the one above: the conformance verdict always belongs to an independent validator, in every edition.

Human-factors note:Human-factors note

Putting the limits before the sales pitch is a deliberate, standards-backed choice. Plain-language guidance is explicit that information most readers need should come before information only some need, and that cautions belong ahead of the instructions rather than after them (SpecSpec: ISO 24495-1, §5ISO 24495-1 §5). For a senior engineer doing tool selection, “where this does not fit” is the information you need first. Reading it should take a minute and save you a great deal of time.

Practical example

This is a short checklist. If any line is true, NextPDF is probably the wrong tool for that job. It may still own a different part of the same system.

Decision check — is NextPDF the wrong shape here?

[ ] You must render arbitrary modern web pages pixel-for-pixel,
    including JavaScript-driven layout.            → use a browser renderer
[ ] Your input is scanned/image-only PDFs you must
    turn into structured, searchable text.         → use an OCR pipeline
[ ] You need a binding PDF/A or PDF/UA pass/fail
    as the authoritative answer.                   → use an independent validator
[ ] The core workload is editing/redacting
    untrusted third-party PDFs.                    → use an editing/redaction tool
[ ] Your runtime is below the supported PHP floor
    and the backport path does not apply.          → use a different toolchain

None of the above ticked?
    → NextPDF is plausibly a good fit. Confirm against
      the design philosophy and the integration decision guide.

Note the asymmetry: ticking a box rules NextPDF out of that job, not out of the system. A pipeline often runs OCR with one tool, generates the final PDF with NextPDF, and validates conformance with a third. Right tool, right stage.

Common misconception

The risk is never the limit you were told. The risk is the limit you discovered in production because nobody would write it down.

A common misreading is treating these as permanent verdicts on the whole system. They are not. “Not the right tool for rendering arbitrary web pages” does not mean “not the right tool for your invoicing service that happens to include a chart”. It means delegate the rendering and keep the generation. The boundary is per-job, not per-project.

Limits and boundaries

This page is itself bounded. It states categories of non-fit, not a ranked list of named alternatives. Naming and comparing specific products is out of scope here by policy. The right specific choice depends on your constraints. The companion integration decision guide maps use cases to the ecosystem’s own components without that comparison.

It is also a point-in-time judgment at this review date. Capability boundaries — especially edition boundaries — can move as the engine evolves. The conformance-verdict boundary, by contrast, is structural and is not expected to move. An independent validator decides conformance regardless of how capable generation becomes.

Where a boundary is genuinely a code behavior, the proof lives on the page that owns it, with that page’s evidence level.

Related docs

• The NextPDF design philosophy — why the engine states boundaries instead of letting you find them.
• The HTML pipeline — what the in-process HTML/CSS engine does and does not cover, and when to delegate to a browser renderer.
• The integration decision guide — a use-case-to-component map across the NextPDF ecosystem, so the choice is yours, not implied.

Glossary

• Editorial (evidence level) — a page that states a deliberate, reasoned judgment, argued rather than measured or quoted from code.
• Necessary, not sufficient — a deliberate phrasing for an in-process check that is a real signal but not a conformance verdict; the authoritative ruling belongs to an independent validator.
• Conformance vs support — conformance is a binary property of an emitted document (it satisfies a named profile or it does not); support is a property of the engine (it implements a feature to a declared degree). A validator measures the first; the engine provides the second.
• PDF/A — the ISO 19005 family of profiles for long-term archival PDF. Production of it is an edition capability; the conformance verdict is always an independent validator’s.
• OCR — Optical Character Recognition, turning page images into text. A separate problem category from PDF generation; expanded here on first use.