PDF Generator API for Node.js: What to Look For

Updated October 27, 2026 · 8 min read

An HTML-to-PDF API looks simple from the outside: send HTML, receive a PDF. In production, the hard parts are everything around the render — waiting for fonts and charts, keeping tables together, measuring page numbers, placing signatures, retrying failed jobs, and storing the output safely.

This guide is a checklist for choosing an out-of-the-box PDF generation SDK for Node.js. It also explains where Fork PDF fits, so you can decide whether a managed API is a better trade-off than maintaining your own Puppeteer pipeline.

What the API should handle

• HTML, URL, and templates. Raw HTML for generated documents, a URL for dashboards, and saved templates for repeated invoices or reports.
• Print-ready rendering. A4/Letter support, margins, landscape, page breaks, and deterministic CSS.
• Fonts and assets. Web fonts, images, and charts loaded before capture.
• Layout validation. A way to assert that a table, chart, or signature block did not split.
• Self-healing. A patch-and-re-render loop for common overflow instead of returning a broken PDF.
• Element coordinates. Page numbers and bounding boxes for signatures, totals, TOC anchors, or overlays.
• Dynamic page numbers. A table of contents measured after pagination, not guessed.
• Fillable forms. HTML inputs converted to AcroForm fields, including non-Latin scripts.
• Async delivery. Webhooks, retries, a dead letter queue, and a way to recover failed deliveries.
• Storage choices. Managed storage or bring-your-own S3, with clear retention.

DIY Puppeteer vs a managed API

Quick start with the Fork PDF SDK

An out-of-the-box Node.js SDK should be a small install and a single client call:

npm install forkpdf

const { ForkPDFClient } = require('forkpdf');

const client = new ForkPDFClient(
  process.env.FORKPDF_API_KEY,
  process.env.FORKPDF_PROJECT_ID
);

const result = await client.generate({
  htmlContent: '<h1>Invoice #1049</h1><p>Total: $450</p>',
  format: 'A4',
  downloadBuffer: true
});

// result.pdfBuffer contains the PDF

Where Fork PDF fits

Fork PDF is built around the parts that are hardest to add later:

• Coordinates: query the rendered DOM for page numbers, bounding boxes, and styles; return custom keys in testResults.
• Self-healing: a test case can detect a split chart, stranded footer, or overflowing table, return a patch, and re-render before delivery.
• Dynamic TOC: measure every heading after layout and inject the finished TOC in the same call.
• Forms: pdfForm: true converts inputs to AcroForm fields; targetLang embeds fonts for Hindi, Thai, Japanese, Chinese, and Korean.
• Accessibility: an experimental PDF/UA-2 path generates a tagged PDF 2.0 candidate through compliance: { pdfUa: 2 }; review its limitations before relying on it.
• Delivery: webhooks, retries, a 3-day DLQ, and managed or BYO-S3 storage.

If you only need a one-page HTML snapshot, a local Chromium script may be enough. If your documents have variable content, page-number requirements, signatures, or audit trails, the layout-feedback layer is where the engineering time goes.

Questions to ask before choosing

1. Can the API return element coordinates without a second parser?
2. Can it detect and repair a broken page break?
3. Does the TOC resolve real page numbers after layout?
4. Can it produce fillable forms in the languages you need?
5. Can it produce a tagged PDF/UA-2 candidate, and what human accessibility checks remain?
6. What happens when a webhook fails?
7. Where are generated documents stored, and for how long?
8. What are the request, payload, and output limits?
9. Is the SDK typed, documented, and usable from Node.js without a browser install?