Laravel HTML to PDF: Convert Blade Views to PDF, dompdf to API

For a plain invoice or receipt, barryvdh/laravel-dompdf is still the right first reach. It is the most downloaded Laravel PDF package ever for a reason: it is a thin wrapper around the pure PHP dompdf library, it renders a Blade view directly, it needs no external binary and no browser, and because it skips a layout engine and a JS runtime it is the fastest in-process option you have.

use Barryvdh\DomPDF\Facade\Pdf;

$pdf = Pdf::loadView('invoices.show', ['invoice' => $invoice]);
return $pdf->download("invoice-{$invoice->id}.pdf");

The wall you hit is CSS. dompdf supports CSS 2.1 and little more, so there is no flexbox, no grid, and no utility classes. In 2026 most Laravel apps style with Tailwind, and dompdf simply cannot render a Tailwind template, the layout collapses. So the rule is clean: if you are willing to write plain, table based CSS by hand for that one document, dompdf is fast and free and you are done. If your template shares the Tailwind design system the rest of your app uses, dompdf is a dead end and you need a browser.

When the template needs a real browser, the community answer is spatie/laravel-pdf, which drives headless Chromium through Browsershot. You render a Blade view and get back a PDF that matches Chrome exactly, Tailwind, flexbox, grid, web fonts, even JavaScript charts all behave, because the same engine your users see is doing the rendering.

use Spatie\LaravelPdf\Facades\Pdf;

Pdf::view('invoices.show', ['invoice' => $invoice])
    ->format('letter')
    ->save("invoice-{$invoice->id}.pdf");

The cost lands in your infrastructure. Browsershot needs Node and a Chromium install sitting next to your PHP, so your Docker image grows and your deploy now manages a browser. Cold Chromium launches add roughly 300 to 800ms per render, which is fine for an occasional download and painful under load, so the usual fix is a queue worker that keeps a Chromium process warm. Browsershot is an excellent choice when a browser is welcome in your environment. It does not remove the browser; it commits you to operating one. The HTML to PDF in PHP guide walks through the same setup with code.

If you inherit a Laravel app that makes PDFs with barryvdh/laravel-snappy, know what is under it. Snappy wraps wkhtmltopdf, and wkhtmltopdf was formally archived by its maintainer in early 2023, no more releases, several CVEs that will never be patched, and a rendering engine frozen on a years old WebKit fork whose CSS support stopped advancing around 2014. If the existing PDFs render correctly there is no emergency, but do not build new features on it and plan a migration off the binary. The full case and the safe replacements are on the wkhtmltopdf alternative page.

The fourth option gives you Browsershot level fidelity without putting Chromium in your app at all. A hosted rendering API runs managed Chromium on its own servers, so from Laravel it is a single HTTP request, no Node, no browser install, no memory pool to tune, and it works on managed and serverless hosts where you cannot launch a browser at all.

use Illuminate\Support\Facades\Http;

$res = Http::withToken(config('services.sitepdf.key'))
    ->asMultipart()
    ->post('https://api.sitepdf.com/v1/render', [
        ['name' => 'url',     'contents' => route('invoices.show', $invoice)],
        ['name' => 'format',  'contents' => 'Letter'],
        ['name' => 'archive', 'contents' => 'true'],
    ]);

$pdfUrl = $res->json('pdf_url');

Point it at a Blade route with route() and Chromium loads the page just as a visitor would, or post a rendered HTML string instead. That archive=true flag is the capability no local package offers: it stores a timestamped snapshot of exactly what was rendered, retrievable by id, so months later you can prove what a given invoice looked like when you produced it. For finance heavy Laravel apps that record is often the whole reason to render through an API. See the PDF generator API page for the full call and the website archiving page for how the record works.