Every product eventually needs to produce a PDF: an invoice, a report, a packing slip, a certificate. And every team discovers the same thing: PDF generation libraries are either painfully low-level (draw text at coordinates) or render HTML with a fraction of the CSS your designer used.

The approach that consistently works is rendering HTML with a real browser engine. Headless Chrome prints HTML to PDF exactly the way Chrome prints a page, which means flexbox, grid, web fonts, and print stylesheets all behave. The catch: running headless Chrome in production means babysitting a heavyweight binary, cold starts, memory spikes, and zombie processes.

That is the entire reason HTML-to-PDF APIs exist. You POST HTML, a managed Chrome renders it, you get a PDF back. This guide shows how to do it with ToolForte's free endpoint, and how the paid options compare when your volume grows.

Convert HTML to PDF with One Request

The ToolForte render endpoint accepts an HTML document and returns a hosted download URL that stays valid for 24 hours:

`bash curl -X POST https://toolforte.com/api/v1/render/html-to-pdf \ -H "Content-Type: application/json" \ -d '{"html": "

Invoice #42

Total: EUR 99

The response contains the PDF URL, its size, and your remaining allowance:

`json { "ok": true, "data": { "url": "https://...signed-url.pdf", "expiresAt": "2026-08-29T21:00:00.000Z", "bytes": 13870, "contentType": "application/pdf", "metering": { "source": "anonymous", "remaining": 2 } } } `

No API key is needed for the first 3 renders per day, which is enough to evaluate output quality. A free key from the developer portal raises that to 50 renders per month; beyond that, renders cost 1 credit each with packs starting at EUR 5 for 50 on the pricing page. Options: pass "format": "Letter" for US paper or "landscape": true for landscape orientation. Full details live in the OpenAPI spec.

Why a Real Browser Engine Matters

PDF libraries that parse HTML themselves (wkhtmltopdf and most pure-language libraries) froze their CSS support years ago. Rounded corners work, grid does not, custom properties are a lottery. You end up maintaining a second, dumbed-down stylesheet just for PDFs.

Headless Chrome removes that entire class of problems:

• Modern CSS: flexbox, grid, custom properties, @page rules for margins and page sizes
• Web fonts: Google Fonts and self-hosted fonts render as designed
• Print stylesheets: @media print applies, so one HTML source serves screen and paper
• SVG and canvas: charts and logos render as vectors, not blurry screenshots

The ToolForte endpoint runs headless Chrome server-side with printBackground enabled, so background colors and full-bleed designs survive the conversion.

For AI Agents: the Same Render over MCP

A growing share of PDF generation is not triggered by application code but by AI agents assembling documents on demand. For that audience the same renderer is exposed through the ToolForte MCP server: add https://toolforte.com/api/mcp/mcp to Claude, Cursor, or any MCP client and the agent gets an html_to_pdf tool (plus url_to_pdf, url_screenshot, qr_code_png, and pdf_merge).

Because the tool returns a hosted URL instead of inline bytes, an agent can generate a report and hand the download link straight to the user, without the host application touching file storage. Cloud agents without any execution environment (a plain claude.ai conversation, an n8n workflow) get PDF generation they otherwise simply cannot do.

How the Free Tiers Compare in 2026

Honest comparison, because your volume determines the right choice:

| Service | Free tier | Paid entry | |---|---|---| | ToolForte | 3/day anonymous, 50/month with free key | EUR 5 one-time for 50 credits, no subscription | | PDFShift | 250/month | subscription | | CraftMyPDF | 50 credits/month | ~$24/month | | CloudConvert | 10/day | credit packs | | DocRaptor | 5/month (unlimited watermarked tests) | ~$15/month | | Api2Pdf | none | ~$0.005 per PDF, pay per use |

For steady high volume (thousands per month), a subscription service or self-hosting Chrome yourself becomes cheaper. For low and bursty volume (invoices for a small SaaS, documents from AI agents, CI artifacts) prepaid credits without a subscription are hard to beat: EUR 5 buys 50 renders that never expire.

Whichever service you pick, test with your real templates first. CSS fidelity, font loading, and page-break behavior differ more between services than their pricing pages suggest.

Practical Tips for Clean PDF Output

A few things that improve every HTML-to-PDF result, on any service:

• Set explicit page rules. Use @page { size: A4; margin: 20mm } in a print stylesheet instead of relying on defaults.
• Control page breaks. break-inside: avoid on table rows and cards prevents awkward splits; break-before: page starts chapters on a fresh page.
• Inline critical assets. Data-URI small images and inline your CSS; a render that races a slow CDN produces flaky output.
• Mind the 1MB input limit. Large base64 images inflate HTML quickly; resize images to their printed size first (the Image to PDF tool handles pure image bundles in the browser for free).
• Post-process with PDF tools. Need to combine renders? The PDF merge endpoint or the free browser PDF tools stitch documents together afterwards.

Generated PDFs are stored for 24 hours on a signed URL and then deleted automatically, so download and persist them on your side if you need them longer.