HTML-to-PDF conversion

For a backend service that converts HTML into PDFs, my default recommendation is a Chromium-based rendering API, such as Browserless or DocRaptor, depending on how much control you need. If you want to run everything yourself, Playwright is a strong option.

The best choice depends on whether your HTML contains complex CSS, web fonts, JavaScript-rendered content, headers and footers, or large batches of documents.

The key distinction is between a hosted HTML-to-PDF API (send HTML, receive a PDF) and a browser automation library (you manage the browser, rendering, and infrastructure).

Best HTML-to-PDF APIs compared

These are the options I'd shortlist for a production backend, based on the rendering engine, deployment model, and document requirements.renderscreenshot.com+1

1. Browserless — Best for browser-based rendering

(Best general-purpose API)

Send raw HTML or a URL to a REST endpoint and receive PDF bytes. Good when you need Chromium rendering, custom CSS/scripts, or browser automation.

Docs: PDF API reference ·Website

2. DocRaptor — Best for print-quality documents

Uses the Prince rendering engine, making it a strong choice for long reports, books, contracts, page numbering, running headers, and advanced print CSS.

Docs: API documentation ·Website

3. PDFShift — Best for simple integration

A focused conversion API for HTML and URLs, with Chromium rendering and options for asynchronous workflows. Worth comparing if you want a straightforward managed service.

Website and documentation

4. Gotenberg — Best for self-hosting

An open-source HTTP API you run in Docker. It uses Chromium for HTML conversion and avoids per-document SaaS fees, but your team operates the infrastructure.

Documentation and quick start

5. API2PDF — Best to evaluate for variable workloads

A managed API with multiple rendering engines and usage-based billing. Potentially attractive when volume fluctuates or your service also needs other document conversions.

Website and API documentation

Which should you choose?

Your requirement	My pick
Existing HTML/CSS templates, hosted API	Browserless or PDFShift
Advanced print layout and publishing	DocRaptor
No external PDF vendor; run in your infrastructure	Gotenberg
Variable usage and multiple conversion formats	API2PDF
HTML already rendered in a Node.js app	Playwright or Puppeteer

These recommendations reflect the tools' differing rendering engines and deployment models; actual cost and fidelity should be tested against your own templates.renderscreenshot.com+1

Example: generate a PDF from HTML

With Browserless, a Node.js backend can submit raw HTML and save the returned PDF bytes.docs.browserless.io

const response = await fetch(
  `https://production-sfo.browserless.io/pdf?token=${process.env.BROWSERLESS_TOKEN}`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      html: `
        <!doctype html>
        <html>
          <head>
            <style>
              @page { size: A4; margin: 20mm; }
              body { font-family: Arial, sans-serif; }
              h1 { color: #2457a7; }
            </style>
          </head>
          <body>
            <h1>Invoice</h1>
            <p>Generated by our backend.</p>
          </body>
        </html>
      `,
      options: {
        format: "A4",
        printBackground: true,
      },
    }),
  }
);

if (!response.ok) {
  throw new Error(`PDF generation failed: ${response.status}`);
}

const pdfBuffer = Buffer.from(await response.arrayBuffer());
// Store pdfBuffer in object storage or return it to the caller.

For production, also set request timeouts, limit concurrency, handle retries carefully, and validate that the response is a PDF. If you accept arbitrary HTML or URLs, protect against server-side request forgery (SSRF), internal network access, and untrusted scripts.

One question to narrow it down

What does your backend use, and approximately how many PDFs will it generate?

Backend stack

Node.js / TypeScript

Python

Java / Kotlin

.NET / C#

Go

Other

Expected volume

Under 1,000 per month

1,000–10,000 per month

10,000–100,000 per month

Over 100,000 per month

Deployment preference

Managed API; minimal operations

Self-hosted; data stays in our infrastructure

Either; optimize for cost and reliability

HTML complexity

Standard web CSS, invoices, receipts

JavaScript-heavy pages or dynamic charts

Advanced print layouts, headers, footnotes, page numbering

[Find the best fit]

When selecting an HTML-to-PDF generation API for a backend service, the "best" option depends on whether you prefer a managed cloud API (zero maintenance) or headless browser automation (maximum CSS/JS control).

Top choices are organized below by category, highlighting their key strengths:

1. Dedicated Cloud & Managed APIs (Best for Zero Infrastructure Overhead)

• • PDFShift : Highly reliable, fast headless-Chrome-based API known for handling complex modern CSS, flexbox, grid, and web fonts seamlessly without maintaining a server cluster.
• • DocRaptor : Powered by the PrinceXML engine rather than standard browsers. It is exceptional for multi-page print-ready documents, robust headers/footers, and complex CSS Paged Media specifications, though it comes at a higher enterprise price point.apryse.com+1
• • Api2Pdf : Incredibly cost-effective and scalable wrapper offering multiple rendering engines under the hood (including Headless Chrome and LibreOffice) with pay-as-you-go or low flat-rate tiering.api2pdf.com
• • PDF Generator API : Tailored specifically for documents like invoices, receipts, and labels where you populate a visual template with JSON data rather than raw arbitrary web HTML.nutrient.io

2. Self-Hosted Headless Browsers (Best for Full Control & Cost at Scale)

If you have the capacity to manage containerized infrastructure (e.g., AWS ECS or Kubernetes), running your own rendering engine via code is often cheaper at high volumes than paying per-request API fees:

• • Playwright : Currently preferred over Puppeteer due to superior modern web standards support, resilient auto-waiting, and stable headless Chromium rendering.
• • Puppeteer : The classic Node.js library for controlling headless Chrome. Great if your stack is already heavily JavaScript/TypeScript-oriented.

Comparison & Selection Guide

To help narrow down the ideal choice, let me know:

• What is your estimated monthly volume of PDFs?
• Do you need support for complex JavaScript, charts, or heavy CSS frameworks (like Tailwind)?
• Are you open to managing your own infrastructure or do you strictly need a fully managed cloud API?