Making invoice PDFs in the browser: page breaks, money maths and one trade-off

Abdul Ahad — Fri, 16 Oct 2026 14:33:58 +0000

I run a free invoice generator, PDF Bill Builder. The PDF is built entirely in the visitor's browser, so nothing is uploaded unless they sign in to save a document. Three problems took longer than I expected. Here is how each one ended up.

1. Render the preview, then slice it

The design lives in one React component: the live preview. To keep the download identical to the preview, I capture that same DOM with html2canvas-pro and place the image into a PDF with jsPDF. The preview has a fixed width (794px for A4, 816px for US Letter), which makes the pixel to millimetre conversion a single division.

const pxToMm = pageW / el.offsetWidth;
const contentHpx = contentHeightMm / pxToMm;

The trade-off, stated plainly: the result is an image inside a PDF. The text is not selectable. For invoices that people send and print this is usually fine, but if you need selectable text or accessibility, use a text-based PDF library instead. In return I get exact visual parity, any font, any currency symbol, and a logo that just works.

2. Never cut a row in half

A long invoice needs several pages. Slicing the canvas every pageHeight pixels cuts table rows through the middle. The fix is to let the preview mark which elements may not be split:

<tr data-pdf-block> ... </tr>

Before slicing, I collect the top and bottom y-position of every marked element, relative to the captured root:

root.querySelectorAll<HTMLElement>("[data-pdf-block]").forEach((el) => {
  const r = el.getBoundingClientRect();
  ys.add(Math.round(r.top - rootTop));
  ys.add(Math.round(r.bottom - rootTop));
});

For each page I pick the largest candidate that is no further than one page height from the start, and no earlier than 35% of the page, so I never produce a nearly empty page. If a single block is taller than a page, I fall back to a hard cut. Page numbers are drawn on multi-page documents.

3. Money maths: one pure function

Tax added on top versus already included, a percentage or fixed discount, and 18 currencies all multiply the edge cases. I moved everything into one pure function, so the preview and the PDF read the same numbers and cannot disagree.

Two details mattered:

Round every line to two decimals, then sum the rounded lines. That matches what the printed invoice shows.
toFixed is not safe for money: 1.005.toFixed(2) gives "1.00". I round half up with a small epsilon instead.

export function round2(n: number): number {
  if (!isFinite(n)) return 0;
  const sign = n < 0 ? -1 : 1;
  return sign * Math.round((Math.abs(n) + Number.EPSILON) * 100) / 100;
}

Tax "included" is informational only (the total stays the same), while tax "on top" adds to the total. The function is covered by unit tests, which is the cheapest insurance I found against sending a client a wrong total.

What I would tell my past self

Treat the preview as the single source of truth for layout.
Mark break-safe blocks in the markup instead of guessing in the slicer.
Keep money maths pure and tested, away from React.

If you invoice clients, I would like to hear what is missing. The generator is free with no signup: https://www.pdfbillbuilder.com

I built a PDF invoice generator that never sends your data to a server

Abdul Ahad — Thu, 30 Jul 2026 18:52:24 +0000

Most online invoice tools upload your data. Your client names, your rates, what you earn — it all sits on someone's server. For a tool whose entire job is producing one PDF, that always felt like a bad trade.

So I built PDF Bill Builder with a hard rule: nothing leaves the browser.

The stack

Next.js 16 (App Router) + React 19 + TypeScript
jsPDF + html2canvas for PDF generation — both dynamically imported, so they only load when someone actually clicks Download
Tailwind CSS v4 for the marketing pages; the tool itself uses inline styles (deliberate — see below)
Optional tier: Neon Postgres + Google OAuth + HMAC-signed tokens

Why the tool uses inline styles

The PDF is rendered by rasterising the live preview DOM with html2canvas. Any style that isn't computed at capture time silently disappears from the output. Tailwind's utility classes were fine until a CSS-layer ordering change dropped borders from the PDF but not the screen. Inline styles removed a whole class of bug where the preview and the PDF disagreed.

The A4 auto-fit problem

An invoice with 3 line items and one with 30 both need to look right on one page. The preview measures its own rendered height and applies a transform scale so content always fits A4, then html2canvas captures at the scaled size. Simple, and it beat every "paginate manually" approach I tried.

What client-side actually buys you

No server means no database of invoices, no breach surface, and no privacy policy gymnastics. It also means no server costs, which is why the free tier can be genuinely unlimited instead of a trial in disguise.

The trade-off: no cross-device sync unless you sign in. That felt like the right default for a tool people use once a month.

Code: https://github.com/Ahad-Khan2401/invoice-generator

Happy to answer questions about the jsPDF pipeline — it was the fiddliest part by far.

DEV Community: Abdul Ahad