How to Generate PDFs from HTML - Browser Tools, Headless Browsers, and PDF APIs

# How to Generate PDFs from HTML - Browser Tools, Headless Browsers, and PDF APIs

The problem that refuses to die

Every product eventually needs to produce a document. An invoice after checkout, a certificate after a course, a report at month end, a packing slip for the warehouse. The data is already in your app, the layout is easy to describe in HTML and CSS, and yet the step from "HTML in a browser tab" to "PDF a customer can keep" is still one of the most annoying gaps in web development.

The reason is that PDF is a print format and HTML is a screen format. Page breaks, headers and footers, font embedding, and exact pixel placement are all things browsers handle internally when you hit Ctrl+P, but exposing that pipeline to your own code means either running a browser somewhere or paying someone else to run one.

There are four realistic ways to do it in 2026. Which one is right depends almost entirely on one question: is a human clicking a button, or is software generating documents on its own?

---

Option 1: Browser-based converters (one file, right now)

If you have a file in front of you and you need a PDF of it once, you do not need infrastructure. You need a tab.

Our own HTML to PDF converter takes markup and produces a PDF entirely in your browser. Nothing is uploaded, which matters when the document is a contract or an internal report. The same applies to Word to PDF for .docx files, and the PDF toolkit for merging, splitting, and reordering pages after the fact. If the result needs a stamp, there is a PDF watermark tool, and PDF to Text goes the other direction.

What it does well:

• Zero setup, zero accounts, works offline once loaded
• Private by design, the file never leaves your machine
• Free, with no per-document counting

What to know:

• A human has to click. There is no API, so it cannot run inside your checkout flow or a nightly job.
• Browser-side rendering has limits on very large or very complex documents.

Verdict: the right answer for one-off conversions, and the wrong answer for anything automated. The moment you think "every order should get one of these," move down this list.

---

Option 2: Client-side JavaScript libraries

Libraries like jsPDF and pdf-lib generate PDFs in the user's browser from your own code. They are a good fit for a narrow case: the user is present, the document is simple, and you want to avoid any server involvement.

What it does well:

• No backend at all, the PDF is assembled on the user's device
• pdf-lib is excellent for modifying existing PDFs (filling fields, stamping pages)
• Fine for receipts, tickets, and simple single-page output

What to know:

• You are not rendering HTML. You are drawing a document with a JavaScript API, or rasterizing the page with html2canvas, which produces a screenshot pretending to be a document: text is not selectable, files are heavy, and it breaks on fonts and scroll containers.
• CSS support is nowhere near what a real browser engine gives you. Tables that span pages, running headers, and page numbers are all manual work.
• It runs on the user's device, so it cannot generate anything when the user is not there.

Verdict: use pdf-lib when you need to manipulate PDFs in the browser. Do not try to rebuild your invoice template in canvas calls.

---

Option 3: Self-hosted headless browser

This is the classic answer: run Chromium on a server via Puppeteer or Playwright, load your HTML, call the PDF function, return the file. It works, the rendering is pixel-perfect because it is a real browser, and the libraries are free.

It is worth saying clearly that wkhtmltopdf, the old default in this category, is no longer a serious option. The project is archived, unmaintained, and built on a WebKit engine old enough that modern CSS simply does not render.

What it does well:

• True browser rendering, so anything Chrome can display, you can print
• Full control over headers, footers, page size, and margins
• No per-document cost beyond your own compute

What to know:

• You are now operating browser infrastructure. Headless Chromium is memory-hungry, leaks under load, and needs queues, timeouts, retries, and restarts to survive real traffic. The failure mode is rarely gentle: it tends to show up at month end, exactly when every customer generates their statement at once.
• Fonts are your problem. So are CJK glyphs, emoji, and that one customer whose name renders as boxes.
• It is a security liability. A service that renders arbitrary HTML on your network is a server-side request forgery target, and it needs to be sandboxed away from anything with credentials.

Verdict: the right choice when you have the ops capacity, strict data residency needs, or enormous volume where per-document pricing stops making sense. Budget real engineering time for it, not an afternoon.

---

Option 4: A hosted PDF API

The fourth option is to send your HTML (or a template plus JSON data) to a service whose whole job is rendering documents, and get a PDF back. This is the category to reach for when documents are generated by software rather than people: every order, every signup, every month end.

The one we recommend is PDFPipe. Disclosure up front: it is built by the same developer behind ToolBox, so weigh that as you like. It is also, genuinely, the tool this comparison kept pointing at.

The model is one request in, one document out:

curl https://api.pdfpipe.xyz/v1/pdf \
  -H "Authorization: Bearer pp_live_..." \
  -d '{"template":"invoice-gst","data":{"order":"#4012"}}'

The response is a hosted PDF URL, typically in around a second, with webhooks available for big batches.

What it does well:

• Accepts raw HTML, a URL, or a template ID with JSON data, so your application code stays small
• Flat pricing per plan with no credit system: the free tier is 500 documents a month, paid plans run from $19 a month for 3,000 documents up to $99 for 50,000, with metered pay-as-you-go beyond that
• Rendering happens in isolated sandboxes with no credentials and no route to private networks, which is exactly the posture you want from a service whose input is arbitrary HTML
• There is a no-signup playground on the homepage, so you can paste HTML and see the output before creating an account
• Ships an MCP server and agent-readable docs, so AI coding agents can wire it up in one shot

What to know:

• It is a young product. The template editor is still on the roadmap, though the API itself is live and usable today.
• As with any hosted renderer, your document content transits a third party. For most invoices and reports that is fine; for genuinely sensitive material, weigh option 3.

Verdict: the default for programmatic document generation. The free tier is large enough to ship a side project on without entering a card, and the flat pricing means you can predict the bill before you integrate.

---

Quick comparison

---

How to decide in 30 seconds

Ask who triggers the document.

If the answer is "me, occasionally," open the HTML to PDF tool and be done with it. If the answer is "the user, in their own browser, for something simple," pdf-lib will carry you. If the answer is "our code, on every order," you want a real rendering engine behind an API, and the only real decision left is whether you operate it yourself or let PDFPipe operate it for you. Unless you already have a platform team that wants to own a fleet of headless browsers, that is an easy call.