HTML to PDF Node.js: Convert HTML to PDF in JavaScript and Generate PDFs Server Side

Ask any Node developer how to make a PDF from HTML and the answer is Puppeteer. It is the right answer on fidelity. Puppeteer drives the same Chromium your users run, so flexbox, grid, Tailwind, web fonts, SVG and JavaScript rendered charts all come out exactly as they look in Chrome, and page.pdf() emits real vector text that stays selectable and searchable.

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.goto('https://app.example.com/invoices/8842', {
  waitUntil: 'networkidle0',
});
const pdf = await page.pdf({ format: 'Letter', printBackground: true });
await browser.close();

The cost is operational, and it is larger than it looks in a tutorial. Installing Puppeteer downloads a full Chromium build, which is a few hundred megabytes sitting in your image. Each launch() spawns a real browser process, so cold starts add roughly 300 to 800ms before a single pixel is painted, and under concurrency you are managing a pool rather than calling a function. Two failure modes bite in production: printBackground defaults to false, so backgrounds and colored table headers silently vanish unless you set it, and if anything throws between launch() and close() the Chromium process leaks, holding memory and file descriptors until the container dies. Puppeteer is a genuinely good tool. It just is not a library, it is a browser you now operate.

Playwright renders PDFs through Chromium exactly as Puppeteer does, and the output is equivalent. Note that PDF generation is Chromium only in Playwright, so the cross browser support that is its main selling point does not apply here. The real reason to choose it is that you already run it: if your test suite is Playwright, reusing that dependency and its browser management is less to maintain than adding Puppeteer alongside it.

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://app.example.com/invoices/8842');
await page.pdf({ path: 'invoice.pdf', format: 'Letter', printBackground: true });
await browser.close();

Everything said about Puppeteer operations applies unchanged: the binaries are large, the browser lifecycle is yours, and serverless needs special handling. Choosing between the two is a dependency question, not a rendering one.

A large share of the confusion around JavaScript PDF generation comes from mixing up browser libraries with server ones. html2pdf.js is the most searched name in this space, and it cannot help a Node backend. Its own documentation is unambiguous: "html2pdf.js will not run in Node.js, it must be run in a browser."

Even in the browser, it is worth knowing what it does. html2pdf.js is a wrapper around html2canvas and jsPDF, and the README states plainly that it "renders all content into an image, then places that image into a PDF. This means text is not selectable or searchable, and causes large file sizes." That single design decision explains most of the problems people hit with it: text that cannot be copied or indexed, blurry output when zoomed, files several times larger than they should be, and, on long documents, completely blank PDFs when the page exceeds the browser maximum canvas size. Page breaks reflow because the library resizes the root element to fit a PDF page.

None of that makes it a bad library for its actual job, which is a client side download button on content already rendered in a tab. It just is not a server side HTML to PDF solution, and no amount of npm configuration will make it one. The html2pdf.js blank pages and page break guide works through the specific failures and the fix for each.

There is a whole family of Node PDF libraries that never touch HTML. PDFKit gives you an imperative drawing API, and pdfmake takes a JSON document definition and lays it out. Both are pure JavaScript, both are small, both run anywhere Node runs including the tightest serverless function, and both produce real vector text.

import PDFDocument from 'pdfkit';

const doc = new PDFDocument({ size: 'LETTER' });
doc.pipe(fs.createWriteStream('invoice.pdf'));
doc.fontSize(20).text('Invoice 8842', 72, 72);
doc.fontSize(10).text('Due 15 September 2026');
doc.end();

The tradeoff is that you are writing a layout engine by hand. If your document is a fixed invoice generated from a database row, that is fine and often preferable: no browser, no CSS surprises, milliseconds per document. If your document is an existing HTML template that your designers maintain, or a page that already exists in your app, rebuilding it in drawing calls is weeks of work and every design change becomes an engineering ticket. Pick by where your document lives, not by which library is trendier.

This is where most teams abandon the local browser approach, and the reason is a hard platform quota rather than anything about your code. AWS Lambda caps the unzipped contents of a deployment package, including layers and custom runtimes, at 250 MB (the zipped upload limit is 50 MB). A standard Chromium build does not fit. That is why the workaround ecosystem exists: @sparticuz/chromium-min paired with puppeteer-core strips Chromium down far enough to squeeze under the limit, or you switch to a container image, which raises the ceiling to 10 GB but changes your whole deployment model.

// The workaround, not a solution
import chromium from '@sparticuz/chromium-min';
import puppeteer from 'puppeteer-core';

const browser = await puppeteer.launch({
  args: chromium.args,
  executablePath: await chromium.executablePath(REMOTE_CHROMIUM_URL),
  headless: true,
});

Assume you get it deployed. The constraints keep pressing. Chromium is memory hungry, and Lambda allocates CPU in proportion to memory, with one full vCPU only arriving at 1,769 MB, so an underprovisioned function renders slowly and an adequately provisioned one is expensive to keep warm. Cold starts now include a browser launch. The 15 minute maximum timeout is generous, but a large report that renders in 40 seconds still ties up an expensive execution environment for 40 seconds. And the leaked browser problem is worse here than anywhere, because serverless containers are reused between invocations, so one unhandled throw before close() leaves a Chromium process alive to poison the next request.

Every one of those problems is caused by the browser being inside your function. Move the browser out and they all disappear at once, which is the entire argument for the API path below.

A hosted rendering API runs managed Chromium on its own infrastructure. From Node it is a fetch call, so there is no binary to install, no pool to tune, no cold browser launch, and no 250 MB limit to fight. It runs identically on Lambda, Vercel, Cloud Run, a Docker container or your laptop, because from your application it is an outbound HTTPS request like any other.

const res = await fetch('https://api.sitepdf.com/v1/render', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.SITEPDF_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://app.example.com/invoices/8842',
    format: 'Letter',
    margin: 'normal',
    archive: true,
  }),
});

const { pdf_url, archive } = await res.json();

Send a url and Chromium loads the page the way a visitor would, or post an html string if the markup is generated in memory and never served. Output is real vector text, so it stays selectable and searchable, which is the thing the html2canvas based libraries structurally cannot give you.

The archive: true flag is the part no local package offers. It stores a timestamped snapshot of exactly what Chromium rendered, retrievable later by id, so months afterwards you can show what a given invoice or statement looked like at the moment you produced it. If you work in finance, insurance or anything with a records requirement, that dated record is usually the reason to render through an API rather than in process. See the PDF generator API page for the full call surface, website archiving for how the record works, and PDF API pricing for what each vendor in this category charges per 1,000 documents.

The honest limit: an API is a network call, so it adds latency your in process library does not have, and it will not work in an air gapped environment. If you render two documents a week, keep Puppeteer. The case for an API strengthens with volume, with serverless, and with any requirement to prove what you rendered.

Work down this list and stop at the first line that matches you.

• The PDF is built from data, not from an existing page. Use PDFKit or pdfmake. Smallest, fastest, cheapest, and it deploys anywhere.
• The download happens in the browser, on content already on screen. Use html2pdf.js and accept that the text becomes an image, or call a rendering API from your backend if the text needs to stay selectable.
• You render HTML server side, a browser is welcome in your infrastructure, and volume is modest. Use Puppeteer, set printBackground: true, and wrap every render in try/finally so the browser always closes.
• You already run Playwright for tests. Use Playwright and skip the extra dependency.
• You are on Lambda, Vercel or any serverless platform, or you are rendering at volume, or you need a dated record of what was produced. Use a rendering API. Every constraint in this section is caused by the browser living in your function.