Same document source
Render the Blade views already in your application. You do not need to move invoices or reports to another template language.
Browsershot alternative for Laravel
Browser-quality Laravel PDFs.
No browser stack to operate.
Browsershot is excellent when you want direct browser control. BladePDF is for teams that want to keep their Blade views without running Chrome, Node.js, Docker images, or browser workers in production.
Keep existing Blade views
No Node.js in production
Managed Chromium
InvoiceController.php
php
return BladePDF::fromView('pdf.invoice', [
'invoice' => $invoice,
])
->format('A4')
->showBackground()
->render()
->download("invoice-{$invoice->number}.pdf");Blade
stays local
Assets
move safely
Chromium
is managed
The production gap
Launching Chrome is easy. Operating it is the work.
Browsershot provides a polished PHP API over Puppeteer and is a great tool when an application needs direct control of a browser. In production, that browser also brings a Node.js runtime, Chrome system dependencies, security updates, memory pressure, process failures, queue sizing, and worker capacity.
BladePDF keeps Chromium rendering but moves the browser lifecycle and the document workflow around it into a managed service built specifically for Laravel.
Different responsibility
Your app prepares data and HTML. BladePDF handles browser installation, isolation, capacity, recovery, and request controls.
More than a browser call
Local asset transfer, render history, optional storage, async delivery, and signed webhooks are part of the service.
A small migration
Replace the rendering backend, not the document.
The native BladePDF facade is the shortest path to managed features. If you already use Spatie Laravel PDF, the dedicated BladePDF driver lets you change only the selected driver.
Install the native Laravel package
bash
composer require bladepdf/laravel
.env
env
BLADEPDF_API_KEY=blpdf_...
Typical self-hosted flow
php
return Pdf::view('pdf.invoice', $data)
->driver('browsershot')
->format('a4')
->save(storage_path('app/invoice.pdf'));
Managed flow through Spatie
php
return Pdf::view('pdf.invoice', $data)
->driver('bladepdf')
->format('a4')
->save(storage_path('app/invoice.pdf'));
Implementation note.
The Spatie compatibility route requires
composer require bladepdf/spatie-laravel-pdf-driver. Use the native bladepdf/laravel package when you need BladePDF cloud templates, native async rendering, per-request webhooks, or managed PDF storage.
Two good tools, two different goals
Direct browser control or managed PDF infrastructure?
The right choice is less about whether Chromium can generate a PDF and more about who should own the browser platform.
Self-hosted or self-integrated
Choose Browsershot for control
Browsershot is a strong choice when the browser is part of your application architecture and your team wants access to Puppeteer-level behavior.
- ◆ Direct control of Chrome executable, arguments, and browser behavior
- ◆ Offline or private-network rendering on infrastructure you control
- ◆ Freedom to tune the full Node.js and Chromium environment
- ◆ No hosted rendering dependency once your stack is installed
Managed
Choose BladePDF for operations
BladePDF is a strong choice when PDFs are a product requirement but operating browser infrastructure is not a differentiator for the team.
- No Chrome, Node.js, or browser-specific system packages in your app image
- Private local assets are transferred automatically with each render
- Managed concurrency, queues, isolation, recovery, and browser updates
- Render history, optional storage, and async webhook delivery
Managed Blade rendering
Your Laravel application keeps the important work.
BladePDF changes where the browser runs, not where your application data and Blade logic live.
01
Render Blade locally
Laravel resolves the view with your models, policies, localization, helpers, and application data.
02
Attach private assets
The package scans the generated HTML and nested CSS for local images, stylesheets, fonts, and other file references.
03
Generate in managed Chromium
BladePDF applies request controls, runs the isolated browser job, and returns, stores, or delivers the finished PDF.
Browsershot vs BladePDF
A practical production comparison.
Both approaches can produce Chromium-rendered PDFs. The main difference is control versus operating responsibility.
| Capability | Self-hosted Browsershot | BladePDF |
|---|---|---|
| Chrome and Node.js | Install, pin, update, and debug in your runtime | Not required in the Laravel deployment |
| Browser control | Direct Puppeteer and launch-level control | Curated PDF options and readiness controls |
| Private assets | Expose, embed, or make files reachable to the browser | Discover, upload, and rewrite request-scoped assets |
| Scaling | Size workers, memory, queues, and browser processes | Choose managed concurrency; short bursts enter a managed queue |
| Failures | Capture process errors, restart browsers, and retry jobs | Managed browser recovery plus render failure history |
| Storage and delivery | Build with your filesystem, object store, jobs, and callbacks | Optional stored PDFs, signed URLs, native async, and signed webhooks |
| Data boundary | Can remain fully inside your infrastructure | Render payload is processed by a hosted service |
| Cost model | Your compute, engineering, and operations | Service plan based primarily on render capacity |
If the browser itself is part of your product logic, Browsershot’s control is valuable. If Pdf::view() only needs to turn an invoice into a PDF, managed infrastructure often removes more work than it adds.
When not to switch
BladePDF is intentionally less low-level.
BladePDF is a strong fit when
- ✓ Your deploy target makes Chrome, Node.js, or system packages difficult to maintain.
- ✓ Browser memory and worker scaling are distracting the team from product work.
- ✓ Private Laravel assets should render without creating public URLs.
- ✓ You want logs, managed capacity, stored outputs, or async delivery around the render.
Keep Browsershot when
- → You need arbitrary Puppeteer calls, launch arguments, or direct page manipulation.
- → PDF rendering must work without outbound network access.
- → Render data must never leave infrastructure you operate.
- → Your current browser fleet is already reliable, observable, and inexpensive to maintain.
BladePDF tradeoffs
- ! Every render depends on network access to the BladePDF API.
- ! The service processes the HTML, context needed for cloud templates, and attached assets.
- ! Plans impose concrete capacity, queue, payload, time, storage, and bandwidth limits.
- ! A managed API cannot expose every low-level Chrome or Puppeteer control.
Documentation
Continue with the implementation details.
Related guides
Choose the path closest to your current stack.
FAQ
Questions teams ask before choosing the renderer.
Is BladePDF saying Browsershot is a bad choice?
No. Browsershot is excellent when you want direct browser control. BladePDF addresses a different need: Laravel teams that do not want to operate the browser infrastructure.
Will I lose Chromium rendering?
No. BladePDF also renders with Chromium. You trade direct browser-level control for a managed, intentionally constrained PDF API.
Do I have to rewrite my Blade templates?
Usually not. The native package renders existing local Blade views, and the asset pipeline resolves common local images, stylesheets, CSS imports, and fonts.
Can BladePDF run async renders?
Yes. Native async renders require
storePdf(), return after acceptance, and report completion through signed pdf.rendered or pdf.failed events and webhooks.Keep Chromium quality. Remove Chromium operations.
Render an existing Blade invoice through the free plan and compare the output.
$ composer require bladepdf/laravel