html-pdf-node in 2026: A Puppeteer Wrapper Left Behind

Two ways to turn an HTML string into a PDF in Node, side by side. First the html-pdf-node wrapper.

const htmlPdf = require("html-pdf-node");

const file = { content: "<h1>Invoice #1042</h1><p>Total due: $250.00</p>" };
htmlPdf.generatePdf(file, { format: "A4" }).then((pdfBuffer) => {
  require("fs").writeFileSync("invoice.pdf", pdfBuffer);
});

The two calls read almost the same. What differs is the engine underneath, and that gap is where IronPDF for Node.js parts from the wrapper. html-pdf-node is a thin wrapper around Puppeteer, and it is pinned to Puppeteer 10 while Puppeteer, as of 2026, is at version 25, roughly five major versions of Chromium rendering and security fixes back. One disambiguation before going further, because the name invites it. html-pdf-node is not html-pdf. That older html-pdf runs on PhantomJS and is an archived, deprecated project, while html-pdf-node wraps Puppeteer, and the difference matters because their engines and risk profiles have nothing in common.

Full disclosure. We build IronPDF for Node.js at Iron Software, and this read looks at where html-pdf-node's pinned Puppeteer dependency costs a team and where IronPDF renders the same HTML on a current engine.

What does the wrapper save you, and what does it cost?

The appeal is real, and it is the whole point of the library. html-pdf-node removes most of Puppeteer's boilerplate for the common case, so you give it a template object and an options object and get a PDF buffer back, with no browser launch or page object to manage. For a quick internal tool, a one-off script, or a prototype where you want the shortest path from an HTML string to PDF bytes, that reduction in boilerplate is a real convenience rather than a gimmick, and its own CVE record is clean across the GitHub Advisory Database, NVD, and Snyk.

What it does not remove is anything underneath it. Because this is a thin wrapper, the browser download, the container shared-library requirements, and the memory profile are all still there, now one layer removed from the documentation that describes them, so you debug through the wrapper's API instead of Puppeteer's own. It is pinned to Puppeteer 10, so the roughly five major versions of Chromium fixes since do not reach the wrapper's users unless it bumps that dependency, and the commit history shows no such bump in years. Rendering behaviour a project depends on may already differ from what current Puppeteer produces for the same HTML, and any Chromium-level fix from the fifteen versions since is not arriving automatically. Maintenance has gone quiet, with the last npm release in December 2021 and the last commit in March 2024 on a single-maintainer project that is not archived and not deprecated, so it keeps working while a bug report lands on a project with no recent activity.

A pinned dependency is not dangerous on its own, since plenty of stable software runs on deliberately pinned versions. What decides it is whether someone is choosing to stay there or has stopped looking, and the multi-year gap since the last commit points to the second, a different risk profile from a team that pinned a version on purpose and still watches upstream for anything that would change the call.

The one case for staying on it is simple, stable HTML where the gap between Puppeteer 10 and 25 never surfaces and the boilerplate it saves keeps paying off. That is a narrower window than it looks, though, since any rendering inconsistency or Chromium-level fix from the last five versions sends you digging through the wrapper to a pinned dependency nobody is tracking.

html-pdf-node and IronPDF for Node.js, side by side

Capability	html-pdf-node	IronPDF for Node.js
Underlying engine	Puppeteer 10, via generatePdf()	Current Chromium, PdfDocument.fromHtml
Rendering fixes since	None past Puppeteer 10	Tracks current Chromium
Deployment constraints	Inherits Puppeteer's, plus a wrapper	Handled by the engine install
Last npm release	December 2021	Active
Last commit	March 2024	Active
Maintainer count	One	Vendor team

Table 1. html-pdf-node and IronPDF for Node.js across the engine and maintenance questions, from the package's own npm metadata and GitHub repository.

The same HTML on a current engine

Back to the second of the two calls at the top. IronPDF covers the same one-call convenience, and renders the HTML through a dedicated Chromium build the vendor keeps current rather than a five-year-old pinned one.

import { PdfDocument } from "@ironsoftware/ironpdf";

const invoice = await PdfDocument.fromHtml(
  "<h1>Invoice #1042</h1><p>Total due: $250.00</p>"
);

await invoice.saveAs("invoice.pdf");

That is one call from HTML to a saved file, on an engine that tracks current Chromium, so the HTML renders the way a current browser renders it and a Chromium-level fix arrives through the engine update rather than waiting on a wrapper to bump a pin. You can pull IronPDF for Node.js from npm and run it in a couple of minutes, and the guide on HTML to PDF without a stale wrapper walks the path end to end.

The engine you build on is the decision

html-pdf-node does what it promises, a minimal API over Puppeteer with a clean record on its own code. What has shifted is the distance between the version it pins and where Puppeteer is now, roughly five major versions and several years of rendering and security fixes apart, on a project that has gone quiet rather than closing that gap. A thin wrapper is only ever as current as what it wraps, so the real decision before building on it is whether that pinned engine is one you would pick deliberately or one you inherited without looking. When it is the second, IronPDF for Node.js renders the same HTML on an engine kept current for you.

Have you checked which Puppeteer version your tooling is actually running underneath, or is that a layer you have never had reason to look at? Tell us in the comments, we suspect it is the second one until something breaks.

html-pdf-node is an open-source project, and is not affiliated with Iron Software. The details above are drawn from the package's own npm metadata and GitHub repository. If something has changed since, correct us in the comments.