HTML to PDF API: how to choose one in 2026

Most HTML to PDF APIs look alike from their landing pages: send HTML, get a PDF. The differences show up later, when a layout breaks, a quota runs out mid-month, or a security review asks where your customers' invoices are stored. This guide lists the criteria worth checking and the questions to ask of any provider, including PDFOven.

First: do you need an API at all?

Self-hosting is a reasonable choice. If you run containers and render modest volumes, a headless Chromium driven by Puppeteer, Playwright or chromedp works well. Pure in-process renderers like WeasyPrint, Dompdf or OpenHTMLtoPDF avoid the browser entirely if your documents are simple and print-first.

An API makes sense when you do not want Chromium in your deployment: serverless platforms where it does not fit, restricted PaaS environments, small teams that do not want to own browser crashes and font packages, or stacks where the language has no good native option. Our language guides show both routes honestly:

• Node.js, Next.js
• Python, Django
• PHP, Laravel
• Ruby on Rails
• Go
• Java and Spring Boot
• C# and .NET

1. Rendering engine

This decides everything else. There are three broad families:

• Chromium-based. Output matches Chrome's print preview. Modern CSS and JavaScript work. Paged media features such as @page margin boxes are limited to what Chrome supports, so headers and footers usually come from separate templates.
• Dedicated print engines such as Prince. Excellent paged media support: running headers, footnotes, cross-references, fine typographic control. JavaScript and some modern layout features may behave differently from a browser.
• wkhtmltopdf. Old QtWebKit, archived upstream, no flexbox or grid. Some services still run it. Avoid it for new work; see the wkhtmltopdf migration guide.

Ask: which engine and version? Can I test my real templates on the free tier before paying? If your HTML was designed in a browser, a Chromium engine will need the fewest changes. If you are producing books or long reports with complex print requirements, a print engine may be the better fit.

2. CSS and JavaScript support

Test with your real documents. Check flexbox, grid, web fonts, SVG, and right-to-left or CJK text if you need them.

If any part of the page is drawn by JavaScript, such as charts, you need two things: JavaScript execution, and a way to tell the renderer when the page is ready. A fixed delay is fragile. Look for a wait-for-selector option, plus a configurable timeout.

3. Templates

Sending full HTML on every request is flexible but puts layout logic in every client. Many APIs also offer stored templates: you design once, then send JSON data.

Ask: what template language is used? Are there helpers for currency, dates and totals, or do you precompute everything? Can templates be versioned and previewed? Can you still send raw HTML when you need to?

4. Headers, footers and page control

Invoices and reports need page numbers. Check whether headers and footers are supported, how page number and total page count are inserted, and whether margins, paper sizes (A4 and Letter at minimum) and landscape orientation are configurable per request.

5. Limits

Every API has them; check that they are documented.

• Maximum request body size and page count.
• Render timeout and whether you can raise it.
• Rate limits and concurrency.
• What happens at the monthly quota: hard stop, overage billing, or degraded service. A clear error code is much easier to handle than a generic failure.

6. Data retention and security

Your PDFs often contain customer names, addresses and amounts.

Ask: are generated files stored, and for how long? Are request bodies logged? Where is the service hosted? Is there a data processing agreement? Can URLs you render reach internal networks? If a provider stores files to serve them from a link, that may be convenient, but it is also data you now need to account for.

7. Pricing model

Common models are per-render credits, monthly tiers with a render allowance, and per-page pricing. Per-page pricing can surprise you with long reports; per-render pricing can surprise you if previews and retries count. Check whether failed renders count, whether there is a free tier that is large enough to test with, and what overage looks like.

8. AI agent and MCP support

More documents are now produced by AI agents. If that applies to you, check whether the provider offers a Model Context Protocol (MCP) server so tools such as Claude Code and Cursor can render documents directly, and whether the agent can fill stored templates rather than writing HTML from scratch. Our guide to AI agent PDF generation with MCP covers the setup.

How PDFOven answers these questions

For transparency, here is where PDFOven stands on each criterion:

• Engine: Chromium.
• Inputs: exactly one of html, markdown, url, template with data, or template_id with data, posted to https://pdfoven.com/v1/pdf. /v1/image returns PNG or JPEG.
• JavaScript readiness: wait_for_selector and timeout_ms.
• Templates: Handlebars, with helpers including formatCurrency, formatNumber, formatDate, sum, lineTotal, multiply, add, eq and upper.
• Page control: formats A3, A4, A5, Letter, Legal and Tabloid; landscape; margins; scale; header and footer templates with page number and total page spans.
• Limits: errors are JSON ({ "error": { "code", "message" } }), and the monthly limit returns 429 with code quota_exceeded.
• Retention: generated files are not stored.
• Pricing: monthly tiers by render count. Free includes 100 renders per month; paid plans are $12 for 2,000, $39 for 15,000, and $99 for 60,000.
• Agents: a hosted MCP server at https://pdfoven.com/mcp.

PDFOven is not the right fit for everything. If you need advanced print typesetting such as footnotes and cross-references, a print-engine service will serve you better, and if you must render offline, self-hosting is the answer.

Comparing specific providers

We maintain side-by-side pages against other HTML to PDF APIs on the comparisons page. Whichever provider you consider, the most reliable test is the same: take your three most complicated real documents, render them on each free tier, and compare the output page by page.