When not to use NextPDF

Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 Spec Spec: ISO 24495-1 ISO 24495-1 Evidence ¶ Editorial Evidence: Editorial

At a glance

This page is the one a vendor usually does not write: 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.

It is an honest boundary statement, not a feature list with the word “not” in front of it.

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 ( Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 ). A page that only ever says yes fails that test on purpose. This one says no where no is the honest 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 honest 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 recurring theme is the engine’s own honesty. Its in-process conformance checks say so in their own 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 says the same of itself: 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.” The engine declines to overclaim about itself. That is exactly why a page that declines to oversell it is consistent with the engine.

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 a Pro-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 ( Spec Spec: ISO 24495-1, §5 ISO 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.

What the evidence says

This page carries Evidence ¶ Editorial Evidence: Editorial : it makes a reasoned boundary judgment, not a code or benchmark claim, and labels itself honestly as such. Two things keep it from being mere opinion.

• The engine’s own artifacts make the same admissions in their own words: the conformance path declares itself “necessary, not sufficient” and defers the verdict to an independent validator; the quick inspector declares itself “structural triage, not a validator”. The boundary statements here are consistent with how the engine describes itself, not louder than it.
• The discipline of stating the boundary is anchored to Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 (appropriateness recognizability — judging fit from documentation) and Spec Spec: ISO 24495-1, §5 ISO 24495-1 §5 (surface what readers need, and cautions, first).

Where code defines a boundary — for example, the in-process conformance check is non-authoritative, or archival is an edition capability — the pages that own it show that behavior with Evidence { } Code-backed Evidence: Code-backed evidence. This page’s job is the candid map, not the proof of each point.

Practical example

The honest read 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 frequent misreading is that a “when not to use” page is an admission of weakness. It is the opposite: an engine confident enough to draw its own edges is one you can plan around. 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 second 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.

Finally, “editorial” is the honest evidence level. This page reasons. It does not benchmark or quote code. 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.