Choose an integration

Choose an integration

Use this page to match your use case to the integration that handles it. Each recommendation comes only from the package’s composer.json description and stated purpose, both read directly from the source repository. When two integrations overlap, this page names the factor that separates them so you can choose with confidence.

Find the row that matches your situation, then start there.

Start here: what do you have?

You have …	Use	Why (verified purpose)
A Laravel 12 application	nextpdf/laravel	Laravel framework integration: service provider, facade, Portable Document Format (PDF) response helpers.
A Symfony 7 application	nextpdf/symfony	Symfony bundle: dependency injection (DI) services and PDF response helpers.
A CodeIgniter 4 application	nextpdf/codeigniter	CodeIgniter 4 services, library wrapper, and PDF response helpers.
A framework-free PHP app	nextpdf/core directly	No framework integration needed; the engine is a plain library.
HTML that needs a browser Cascading Style Sheets (CSS) engine, and you can run Chrome	nextpdf/artisan	Chrome DevTools Protocol (CDP) renderer for HTML that needs browser-grade CSS layout.
An Office document to convert, such as DOCX, XLSX, or ODT	nextpdf/gotenberg	Office-to-PDF conversion via a Gotenberg microservice.
A need to render with no browser process to operate	nextpdf/cloudflare	Serverless rendering via the Cloudflare Browser Rendering API at the edge.
Code written against a legacy PDF library	nextpdf/compat-legacy	Legacy PDF library compatibility layer; call NextPDF without rewriting call sites.
A runtime stuck on PHP 8.1 / 7.4	nextpdf/backport-builder	Rector downgrade pipeline that builds an 8.1 / 7.4 target of the engine.
Remote callers, another language, or an artificial intelligence (AI) system	nextpdf/server	NextPDF Connect: Representational State Transfer (REST), gRPC, and Model Context Protocol surface for remote execution.

When two integrations could fit

Rendering HTML to PDF: Artisan vs Gotenberg vs Cloudflare vs core

All three renderer bridges turn markup into PDF. They differ in how they operate, not in quality. Use that operational difference as the deciding factor.

• nextpdf/artisan drives headless Chrome over the Chrome DevTools Protocol. It needs a Chrome process that the application can reach. Choose it when you can operate that process and the document needs a browser CSS engine.
• nextpdf/gotenberg calls an out-of-process Gotenberg microservice over HTTP. Choose it when rendering must be isolated in its own service, or when the input is an Office document. Gotenberg is the only one of the three whose stated purpose includes Office-to-PDF.
• nextpdf/cloudflare calls the Cloudflare Browser Rendering API. Choose it when you want edge/serverless rendering with no browser process to run or patch.
• The in-process NextPDF core HTML pipeline needs none of the above. Use a renderer bridge only when the in-process pipeline cannot provide the layout fidelity or process isolation the document needs. A bridge deliberately hands off that step; it is not the default path.

The two HTTP bridges (nextpdf/gotenberg, nextpdf/cloudflare) need a host-supplied PSR-18 HTTP client. Their recipes treat a transport failure and a non-success HTTP status as separate outcomes.

Converting an Office document

nextpdf/gotenberg is the integration whose verified composer.json description names Office-to-PDF conversion. The other renderer bridges describe HTML rendering, not Office input. If the source is DOCX/XLSX/ODT, use this integration.

Migrating off a legacy PDF library

By its stated purpose, nextpdf/compat-legacy is a compatibility layer for codebases written against a legacy PDF library. It lets existing call sites reach NextPDF before you rewrite them. Treat it as a migration aid with a planned removal, not as a permanent runtime dependency. New code should call nextpdf/core (or the relevant framework integration) directly.

Running on PHP 8.1 or 7.4

Every ecosystem package declares PHP >=8.4 <9.0. nextpdf/backport-builder exists for exactly this constraint: its stated purpose is a Rector downgrade pipeline that builds a PHP 8.1+ (and a 7.4 target) artifact. It is a build tool, not a runtime dependency for your application. Run the builder to produce the backported engine, then deploy that engine.

A non-PHP caller or an AI agent

nextpdf/server (NextPDF Connect) exposes the engine over a REST API, a gRPC service, and the Model Context Protocol. Choose it when the caller is remote, in another language, or an AI system that consumes a tool endpoint rather than a PHP library. A PHP application in the same process should use nextpdf/core or a framework integration instead of adding a network hop.

Using more than one integration together

A framework integration and a renderer bridge work at different layers, so you can install both. The framework integration handles container wiring and the HTTP response; the renderer bridge handles the rendering backend. When you resolve a combined dependency set, check which nextpdf/core versions each package accepts. The core-constraint reference in the integration cookbook index is the source of truth. Per-combination recipes live in the relevant repositories and link from that index.

See also

• Integration cookbook — package and core-constraint reference, plus the recipe link index.
• Recipe conventions — the contract every runnable recipe follows.