barryvdh/laravel-dompdf: a Laravel wrapper around Dompdf for HTML to PDF

The problem: turning a Laravel view into a downloadable PDF without leaving PHP

Dompdf is a pure PHP HTML to PDF converter. It has no Laravel awareness: no service provider, no facade, no config file, no Blade integration. Using it directly in a Laravel app means constructing the Dompdf object yourself, pointing it at a font directory, managing a temp directory, and deciding where the chroot boundary sits. That is repeated boilerplate in every project.

barryvdh/laravel-dompdf exists to remove that boilerplate. It registers a service provider, exposes a Pdf facade and a dompdf.wrapper binding in the container, and ships a config file you publish into config/dompdf.php. The audience is Laravel developers who already render HTML through Blade and want the same templates to produce invoices, receipts, tickets or reports. It is not a rendering engine of its own. Every layout decision, every CSS limitation and every font problem belongs to Dompdf, and the wrapper is honest about that in its own description.

What the wrapper actually adds: container binding, facade, and a config layer

The data flow is short. You hand the wrapper either a view name plus data, an HTML string, or a file path. It resolves a Dompdf instance through the Laravel container, applies whatever options are set in config/dompdf.php or overridden at runtime, and returns an object you can save, stream or download.

Three entry points are documented. The Pdf facade is the common one. The container binding dompdf.wrapper gives you the same object without the facade, which matters inside packages or when you want to swap the binding in tests. Method chaining lets a single expression load, save and stream. The wrapper also exposes setPaper for size and orientation, setWarnings to suppress warnings, output() when you want the raw PDF bytes rather than a response, and setOption for per-call overrides such as dpi or defaultFont.

The config file is where the wrapper earns its place. It maps Dompdf's options into Laravel-friendly keys: tempDir, fontDir, fontCache, chroot, defaultPaperSize, defaultFont, dpi, isPhpEnabled, isRemoteEnabled, isJavascriptEnabled, isHtml5ParserEnabled, isFontSubsettingEnabled, isPdfAEnabled, pdfBackend and others. The README marks which of these are settable in config/dompdf.php and which are not. That distinction is worth reading carefully, because a few entries in the list are only adjustable in code.

Installing barryvdh/laravel-dompdf and rendering a first invoice

Installation is a single Composer command. The README states it downloads the package together with the dompdf and fontlib libraries, so there is no second step for the engine itself.

composer require barryvdh/laravel-dompdf

Laravel auto-discovers the service provider. Lumen does not, and the README gives the two lines to add in bootstrap/app.php: registering \Barryvdh\DomPDF\ServiceProvider::class, and calling $app->configure('dompdf') if you want the config file loaded.

To get an editable config file at config/dompdf.php, publish it. The README gives the provider-qualified form.

php artisan vendor:publish --provider="Barryvdh\DomPDF\ServiceProvider"

Now a first real use. Create a Blade view, then return a download response from a route or controller. The README's own example uses the Pdf facade with loadView and download.

use Barryvdh\DomPDF\Facade\Pdf;

$pdf = Pdf::loadView('pdf.invoice', $data);
return $pdf->download('invoice.pdf');

What the reader should see is a file named invoice.pdf arriving in the browser, rendered from the Blade view at resources/views/pdf/invoice.blade.php with $data available inside it. Two practical details from the README matter here. First, set the UTF-8 meta tag in the template, otherwise non-ASCII characters misbehave. Second, page breaks come from the CSS page-break-before and page-break-after properties, not from any wrapper-specific helper. If you need the bytes instead of a response, call output() and handle storage yourself.

Remote assets are off by default since 3.x, and that is the first thing that breaks

The README carries a short note: since 3.x remote access is disabled by default, to provide more security, and it advises using it with caution. The config key is isRemoteEnabled and it defaults to false. The related allowedRemoteHosts key defaults to null.

This is the most common failure mode for anyone migrating an older template. A logo loaded from a CDN, a stylesheet on another domain, a web font fetched by URL: all of them silently do not appear. The template renders, the PDF is produced, and the image is simply missing. The fix is to enable remote access in config/dompdf.php and, better, to constrain it with allowedRemoteHosts rather than opening it entirely. The alternative fix is to inline assets as data URIs or place them on the local filesystem inside the chroot directory, which avoids the setting altogether.

The same class of problem applies to fonts. If you enable PDF/A, the README is explicit that all fonts must be embedded and that the core PDF fonts (Helvetica, Courier, Times) are not embedded and will cause validation failures. It names DejaVu Sans and DejaVu Serif as suitable replacements. That is a concrete, checkable constraint rather than a vague warning, and it is the kind of detail that decides whether an archival workflow is viable.

PDF/A-3b and Factur-X: the wrapper's most specific feature

PDF/A-3b support requires dompdf 3.1.0 or later and the CPDF backend, which the README notes is the default. You can enable it globally in config/dompdf.php under a pdfa key with enabled set to true, or per document at runtime with setPdfA().

For electronic invoicing, the wrapper exposes addEmbeddedFile() and setAdditionalXmpRdf(). The README's example builds a Factur-X invoice by calling setPdfA(), then setAdditionalXmpRdf() with an rdf:Description block carrying fx:DocumentType, fx:DocumentFileName, fx:Version and fx:ConformanceLevel, then addEmbeddedFile() with a path, a filename, a description and a MIME type, and finally download().

This is a narrow feature aimed at a narrow audience: teams in jurisdictions or supply chains that require embedded XML invoices in an archival PDF container. If that is your requirement, the wrapper gives you the hooks without you having to patch Dompdf. If it is not, this section is irrelevant to you and you should not enable PDF/A, because the font embedding requirement adds work for no benefit.

Where it is the wrong tool, and what to reach for instead

Dompdf is an HTML and CSS renderer written in PHP, not a browser engine. Complex layouts, modern CSS, and JavaScript-driven rendering are outside what it handles well. The wrapper does not change that. If your PDFs must match a design pixel for pixel, or if your HTML is generated by a front-end framework, you are fighting the engine, not the wrapper.

The README mentions isJavascriptEnabled defaulting to true, but the presence of a setting is not a claim that script execution produces browser-equivalent output. Treat it as a flag, not a guarantee.

The real alternative in the Laravel world is a headless-browser approach, typically a wrapper around Puppeteer or a similar Chromium-driven renderer. The difference in approach is fundamental. Dompdf parses HTML and CSS in PHP and lays out the document itself, so it runs anywhere PHP runs, with no external process and no browser binary to install or keep patched. A Chromium-based renderer actually renders the page in a browser, so it supports far more CSS and can reuse front-end code, at the cost of a Node or Chromium dependency in your deployment and a heavier process per PDF. There is no universal winner; the choice is between a self-contained PHP pipeline and a rendering fidelity you cannot get in pure PHP.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-07-09. Releases are infrequent rather than continuous: v3.1.0 in January 2025, v3.1.1 in February 2025, and v3.1.2 in March 2026. That cadence is normal for a thin wrapper whose upstream engine does most of the changing.

The practical upgrade cost sits in two places. First, the 3.x line changed a default with real consequences: remote access is now off. Any template relying on remote assets needs the config change described above, and that change should be paired with allowedRemoteHosts rather than a blanket enable. Second, PDF/A support depends on a minimum dompdf version and the CPDF backend, so a future dompdf major bump is the event most likely to require attention here. The repository layout includes phpstan.neon, phpunit.xml.dist and grumphp.yml, which indicates static analysis and a test suite are part of the project's own quality process.

The licence is MIT, which is permissive and compatible with closed-source Laravel applications. That is a statement about the licence text, not legal advice; if you redistribute the package or embed it in a product with unusual licensing constraints, read the LICENSE file and consult your own counsel.

Editorial conclusion

Adopt it when your PDFs are generated from HTML and CSS you already control, when you want the whole pipeline inside a Laravel app with no external binary, and when you can live with Dompdf's CSS subset. Do not adopt it if you need pixel-accurate rendering of arbitrary web pages, or if your templates depend on remote images and fonts, because the README states remote access is disabled by default since 3.x. Before committing, verify two things on a real template: that your chosen fonts embed correctly if you intend to enable PDF/A, and that your CSS avoids features Dompdf does not implement. Everything else is a wrapper around a library you can read separately.

Frequently asked questions

Official sources

1. barryvdh/laravel-dompdf on GitHub
2. Issues
3. License: MIT
4. README
5. Releases