Comparison
A Laravel alternative to Snappy (knp-snappy)
knp-snappy is the most-installed Laravel PDF package. It is a thin wrapper around wkhtmltopdf, a Qt-based binary that has not had an active release since 2020. The rendering engine is based on an old WebKit fork that does not support flexbox properly, has partial CSS3 support, and requires a system binary to be installed on every server, container, and CI environment where your app runs. PDFPipe renders with a modern browser engine from a single HTTP call.
Snappy versus a dedicated PDF API
| PDFPipe | knp-snappy | |
|---|---|---|
| Rendering engine | Modern browser (actively maintained) | wkhtmltopdf (unmaintained since 2020) |
| Flexbox / CSS Grid | Yes | Partial / broken |
| JavaScript execution | Yes | Limited |
| Binary install required | No | Yes (wkhtmltopdf on every server) |
| Docker setup | One HTTP call | Add wkhtmltopdf layer to every image |
| Web fonts | Any URL, loaded automatically | Local files only or fragile URL loading |
| Memory usage | None in your PHP process | Spawns a separate OS process per render |
| Maintenance | Actively developed | Wrapper around an abandoned binary |
The wkhtmltopdf problem
wkhtmltopdf uses the Qt WebKit engine, a fork of WebKit that diverged from the main Safari/Chrome rendering path years ago. Its CSS support is frozen roughly at 2013-era WebKit: flexbox works inconsistently, CSS Grid is not supported, custom properties do not work, and modern font loading is unreliable. The project is effectively unmaintained. knp-snappy exposes all of these limitations directly, because it cannot go beyond what the underlying binary supports.
Deployment overhead
Every environment where your Laravel app runs needs the wkhtmltopdf binary installed: your local machine, every developer's machine, your CI containers, your staging server, and every production node. Different Linux distributions ship different versions, producing subtly different output. On shared hosting, installing system binaries is often not possible at all. PDFPipe requires no binary, no system packages, and no configuration beyond setting an environment variable.
Laravel replacement
Replace the Snappy controller with the Http facade. No new Composer package required:
// Drop-in replacement for the Snappy PDF controller pattern.
// Uses Laravel's built-in Http facade — no new package required.
use Illuminate\Support\Facades\Http;
public function invoice(string $id): \Symfony\Component\HttpFoundation\StreamedResponse
{
$html = view('invoices.show', ['invoice' => Invoice::findOrFail($id)])->render();
$res = Http::withToken(config('services.pdfpipe.key'))
->post('https://api.pdfpipe.xyz/v1/pdf', [
'html' => $html,
'options' => ['format' => 'A4'],
]);
abort_unless($res->successful(), 502, 'PDF render failed.');
return response()->streamDownload(
fn () => print($res->body()),
"invoice-{$id}.pdf",
['Content-Type' => 'application/pdf'],
);
}When to keep Snappy
knp-snappy is an acceptable choice when you have no outbound HTTP from your servers, you control every environment where wkhtmltopdf is installed, and your templates use only basic CSS that wkhtmltopdf supports. For any modern CSS, web fonts, or cloud/container deployments, a render API eliminates an entire class of infrastructure problems.
Full Laravel and PHP examples on the Laravel guide.
See pricing →