When we started InvoicesFox, the first non-negotiable feature was simple: a user fills a form and gets a real PDF, not a screenshot and not a “print this page” hack. We evaluated hosted PDF APIs, headless Chrome farms, and pure PHP renderers. We shipped with Laravel + Blade + DomPDF on our own servers. This post explains why, and the bugs that taught us the most.
Why not a SaaS PDF API?
Third-party renderers are excellent when you need pixel-perfect HTML/CSS and you can pay per document. For a free invoice generator, per-PDF pricing becomes a product decision overnight. We also wanted invoice HTML to live next to the rest of the Laravel app so designers and engineers could iterate on templates without syncing assets to another vendor.
DomPDF is not perfect — CSS support is limited — but for invoices (tables, headers, footers, logos) it is predictable once you design for its constraints.
The rendering pipeline
- Collect invoice state (client, lines, taxes, currency, branding).
- Pick a Blade template that matches the chosen layout.
- Render HTML with absolute URLs for logos where needed.
- Pass HTML to DomPDF with paper size and margins tuned for A4 / Letter.
- Stream or store the binary PDF for download.
The important part is that the same data model feeds the on-screen editor and the PDF. If the editor shows a total of 1,250.00 and the PDF shows 1,249.9997, users lose trust immediately. That led directly to our work on money math (see our multi-currency post).
Layout pitfalls we hit in production
- Long product descriptions — unrestricted wrapping pushed totals onto a lonely last page. We capped description length in the PDF view and kept the full text in the editor.
- Logo sizing — giant PNGs exploded memory. We normalize uploads and constrain height in the template.
- RTL and special characters — invoice notes with mixed scripts need font subsets that DomPDF can embed. We stick to fonts we bundle.
- Page breaks inside tables — we prefer explicit section structure over clever CSS that DomPDF ignores.
What we would still change
For premium custom stationery, a Chromium-based renderer is tempting. For the free path, owning the pipeline keeps costs predictable and debugging local: if a PDF looks wrong, we open the Blade file and reproduce it in minutes.
If you are building something similar, start with one boring template, instrument generation failures, and only then add themes. Fancy layouts are useless if totals disagree with the UI.
Try it yourself on the free invoice generator, or read more in the InvoicesFox blog.