PDFKit in 2026: When a Design Change Becomes a Code Change

#javascript #node #pdf #opensource

A fixed-layout report ships fine in PDFKit. Then a stakeholder asks to move the logo, widen a column, and change a heading colour, and the request lands on a developer's desk instead of a designer's, because the layout only exists as code. There is no template a non-developer can touch.

That is the shape of PDFKit, a coordinate drawing API where the document is built call by call and the design lives in the codebase. IronPDF for Node.js renders the same document from HTML and CSS, so a design change is a template edit, which is the difference this piece is about.

Full disclosure. We build IronPDF for Node.js at Iron Software, and this read looks at where PDFKit's code-owned layout costs a team and where IronPDF renders the same document from HTML.

What PDFKit is good at

PDFKit has earned its ten years. It draws text, vector graphics, and images from a direct coordinate API, streams output rather than buffering a whole document in memory, needs no browser or native dependency, and handles automatic page breaks for long text on its own, which many lower-level drawing libraries leave to the developer. It is MIT-licensed, and it has no CVEs on record across the GitHub Advisory Database, NVD, or Snyk, checked directly rather than assumed. For a document built entirely in code, it is a direct and well-worn tool.

What PDFKit does not do is turn an existing HTML design into a PDF, and that is a different category of tool rather than a missing feature.

Where the coordinate model costs you

There is no HTML or CSS engine at all: PDFKit draws from coordinates, so an existing web page, email template, or design handoff has no path in, and every element has to be re-implemented as text(), rect(), and image() calls with margins and font sizes translated by hand.
There is no native table layout: rows, columns, and cell borders are not a built-in construct, so a real table means positioning each cell and drawing the lines yourself, or pulling in a separate community module.
Every design change is a code change: with no separation between content and presentation, moving a logo or widening a column means editing drawing calls, so a visual tweak from a marketing team lands on an engineer instead of in a template.

PDFKit and IronPDF for Node.js, side by side

Capability	PDFKit	IronPDF for Node.js
HTML and CSS to PDF	Not supported	Supported, `PdfDocument.fromHtml`
Native table layout	Draw each cell by hand	Real HTML tables
A design change	Edit the `doc.text()` calls	Edit the HTML template
Automatic page breaks	Yes	Yes
Read existing text	Not supported	Full text extraction

Table 1. PDFKit and IronPDF for Node.js across the layout questions, from PDFKit's own documentation.

The layout lives in HTML, not the code

IronPDF renders HTML and CSS through a Chromium engine, so a table is a table and the design sits in a template rather than in the code that draws it.

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

const invoice = await PdfDocument.fromHtml(`
  <table style="width:100%; border-collapse: collapse;">
    <tr><td>Invoice #1042</td><td style="text-align:right;">$250.00</td></tr>
  </table>
`);

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

That renders a table from HTML and CSS, so a design change is an edit to the markup, not a rewrite of positioning code. You can pull IronPDF for Node.js from npm and run this in a couple of minutes, and the HTML-to-PDF guide walks the path end to end.

What a direct CVE and maintenance check turns up

This is worth checking directly rather than assuming a ten-year-old library is automatically fine. The GitHub Advisory Database, NVD, and Snyk all come back clean for the npm pdfkit package, which has no CVEs on record. The name causes confusion, because a search for PDFKit surfaces two unrelated codebases. Apple's macOS PDFKit.framework is an Objective-C rendering framework with its own CVE history and nothing to do with this package, and a Ruby gem also called pdfkit shells out to the wkhtmltopdf binary and carries a command-injection CVE from that shell-out design. Neither is the JavaScript library covered here.

Maintenance is current too, with a release in June 2026, a commit within the last day at the time of writing, and over 10,000 GitHub stars ten years into the project. None of that closes the gap this piece is about, though. A clean, well-kept drawing library is still a drawing library, so the open question is not whether PDFKit is maintained but whether your layout should live in code at all.

Where the design lives decides it

The one case for PDFKit is a fixed document a developer owns end to end, generated the same way every time from code, where the coordinate model is the direct tool. That holds only until the design lives outside the codebase, though, since a template, a designer, or a marketing team on its own schedule turns every visual tweak into a code change rather than a template edit.

On that far more common side, the choice is between hand-porting a design into drawing calls or rendering it with IronPDF for Node.js from the HTML it already exists as.

Is your PDF entirely code-owned, or does the layout come from a template, a designer, or a marketing team? Tell us in the comments, that answer decides this one more than any single feature.

PDFKit is an open-source project distributed under the MIT licence, and is not affiliated with Iron Software. The details above are drawn from the project's own documentation, npm metadata, and the GitHub Advisory Database. If something has changed since, correct us in the comments.

DEV Community