The 8 Best HTML to PDF APIs in 2026 (Free Tiers + Pricing)

Q: Can I self-host an HTML to PDF service?

Yes, two main options. Gotenberg is open source (Apache 2.0), runs as a Docker container, and wraps Chromium plus LibreOffice behind a clean REST API. It's the easiest self-hosted option — one `docker run` command and you have an API. Prince is commercial ($3,800 per server license perpetual, or $500/year), but it's the fidelity leader. Break-even versus DocRaptor happens around 25,000 PDFs/month. You can also build your own with Puppeteer or Playwright in a Node.js process, but you'll spend time on things Gotenberg has already solved: font loading, timeout handling, concurrency, memory management.

TL;DR

If you just need an HTML to PDF API that works and costs almost nothing, use PDFShift or PDFcrowd — both have real free tiers (100–500 conversions/month) and predictable per-page pricing after that. If you need pixel-perfect print CSS (invoices, tax forms, legal packets), pay for DocRaptor or self-host Prince. If you want zero per-call cost and control everything, self-host Gotenberg on a $6 VPS. For everything else — including a browser-side option that skips the API entirely — see Convert Anything to PDF.

TL;DR: cheapest at scale, best free tier, best fidelity

Three categories cover almost every real need:

Cheapest at scale — Api2Pdf and PDFShift bottom out around $0.001–$0.003 per PDF at 100K+ documents/month. Api2Pdf is a thin wrapper over AWS Lambda-hosted Chromium, so you pay near cost. PDFShift's enterprise tier gets similar at volume. If you can self-host, Gotenberg on a small VPS handles ~50K PDFs/month for ~$6 in server costs — effectively $0.00012 per PDF, ignoring your time.

Best free tier — PDFShift gives 500 free credits per month, no card. PDFcrowd gives 100/month. Api2Pdf gives $1 in credit (roughly 500–1,000 PDFs depending on engine). Everything else either has no free tier, a trial that expires, or is self-hosted (which is "free" but not really).

Best fidelity — DocRaptor and Prince are the same engine (DocRaptor is Prince as a service). Both handle print CSS features that headless Chromium silently drops: proper page breaks with page-break-inside: avoid, running headers/footers, cross-references, PDF/A output, PDF/UA accessibility tagging, real form fields. If your PDF is going to a printer or a regulator, Prince/DocRaptor is the answer. If your PDF is going to a browser download button, Chromium-based services are fine.

The wrong choice is picking DocRaptor for a project that doesn't need print-level fidelity (it's 10–50× more expensive per document than Chromium-based options), or picking a cheap Chromium wrapper for a project that does (you'll fight page-break bugs forever). Everything else in this post is refinement on those three axes.

The comparison matrix

Service	Free tier	Price per 1K PDFs (paid)	Engine	Best for
PDFcrowd	100/mo	$9 at 1K, ~$3 at 100K	Chromium + WebKit	General web pages, simple invoices
DocRaptor	7-day trial	$15 at 1K, $9 at 100K	Prince	Print-quality, PDF/A, PDF/UA
PDFShift	500/mo	$9 at 1K, ~$2 at 100K	Chromium	Fast, developer-friendly
Api2Pdf	$1 credit	$3 at 1K, ~$1 at 100K	Chromium / wkhtmltopdf / LibreOffice	Cheapest raw price
Prince (self-host)	30-day trial	$3,800 one-time server license	Prince	On-prem print-quality
Gotenberg (self-host)	Fully free (OSS)	Server costs only (~$6/mo VPS)	Chromium + LibreOffice	Cost-sensitive teams with ops capacity
HTMLtoPDF.io	25/mo	$7 at 1K, ~$4 at 100K	Chromium	Simple pricing, small teams
Restpack	100/mo	$12 at 1K, ~$5 at 100K	Chromium	Screenshots + PDFs same API

Prices are list, checked August 2026. Actual pricing varies with annual commits, batch discounts, and enterprise negotiations. All Chromium-based services use roughly the same rendering engine, so fidelity differences on typical web pages are minor — the real difference is uptime, SDK quality, and how they handle edge cases like custom fonts, external assets, and long-running conversions.

For a broader survey of PDF tools including desktop and CLI options, see Best Free PDF Converters 2026.

PDFcrowd

PDFcrowd has been around since 2009, which in API-longevity terms is basically forever. Two engines available: their default Chromium-based renderer, and a WebKit engine that handles some older CSS better than modern Chromium does.

Free tier: 100 credits/month, no card. A credit is one page of output, so a 5-page PDF costs 5 credits.

Pricing: Starts at $9/month for 1,000 credits, scales down to about $3 per 1K at the 100K/month tier. No per-request minimums.

SDKs: Official libraries for Python, Ruby, PHP, Node.js, .NET, Java, Go. All are thin wrappers around the REST API, so if your language isn't listed, a curl call is trivial.

Fidelity: Solid on modern CSS. Handles custom fonts if you pass them via URL or upload. Their --page-size, --margin-*, and header/footer template options match what you'd expect from Puppeteer. Page breaks work with the standard page-break-before/page-break-after CSS.

Gotchas: Their credit system means multi-page documents burn credits fast. A 20-page report is 20 credits, not 1. Watch the math — a "1,000 conversions/month" plan can be exhausted in a few hundred long PDFs.

Use when: You want a stable, general-purpose HTML-to-PDF API with a real free tier and no surprise billing. Not the cheapest, but the "boring, works" option.

DocRaptor

DocRaptor is Prince XML wrapped in a REST API. If you've never worked with Prince, the elevator pitch: it's a rendering engine built specifically for print, with 20+ years of CSS Paged Media support. Things headless Chromium gets wrong (running headers per section, footnotes, cross-references, PDF form fields, accurate widow/orphan control), Prince gets right.

Free tier: 7-day trial, no free monthly tier. This is a paid tool aimed at teams generating invoices, contracts, and reports where fidelity matters.

Pricing: Starts at $15 per 1,000 documents on the entry plan, drops to about $9 per 1K at the top published tier. Enterprise pricing is negotiated. Every document is one billable unit regardless of page count — a 200-page report is one document.

SDKs: Ruby, Python, PHP, Node.js, .NET, Java. Their Ruby gem is the most polished (DocRaptor's founders come from the Ruby world).

Fidelity: This is why you pay. PDF/A-1a and PDF/A-2b output for archival compliance. PDF/UA accessibility tagging for Section 508. Real interactive form fields via <input> elements. Prince-specific CSS extensions like prince-footnote-policy, @page :first, and generated content for cross-references (target-counter()).

Gotchas: Cost. A high-volume marketing site cranking out 100K PDFs/month will pay ~$900/month here versus ~$200 with PDFShift. Only worth it if fidelity or compliance features earn their keep.

Use when: Regulated output (tax, medical, legal), accessible PDFs, complex print layouts, or anywhere a designer has already written the CSS for print and expects it to render like print.

PDFShift

PDFShift is the developer-friendly Chromium option. The API is clean, the docs are good, and the free tier is generous enough for prototyping and small production workloads.

Free tier: 500 conversions/month, no card required. This is the most generous no-card free tier in the category.

Pricing: $9/month for 1,000 conversions, and volume tiers get down to about $2 per 1K at 100K/month. Pricing is per document, not per page — a 50-page report is one conversion.

SDKs: Python, Node.js, PHP, Ruby, Go. Also a raw REST endpoint and a webhook-based async mode for large jobs.

Fidelity: Standard Chromium rendering — matches what you'd get from Puppeteer or Playwright. Supports custom CSS injection, JavaScript execution (for pages that render content client-side), custom headers/cookies (for authenticated pages), and viewport control.

Gotchas: Chromium's usual quirks apply. Print CSS like @page selectors are partially supported, complex page-break rules can misfire, and there's no PDF/A output. For general web content it's excellent; for legal/regulatory output, use DocRaptor.

Use when: You're building a SaaS feature that generates PDFs of dashboards, reports, or web content, and you want an API that "just works" with reasonable pricing and a free tier that survives a real prototype.

Api2Pdf

Api2Pdf is the low-cost option, and it's honest about why: it's a thin API layer over AWS Lambda-hosted Chromium (plus optional wkhtmltopdf and LibreOffice engines). You pay near AWS cost plus a small markup.

Free tier: $1 in credit on signup, which translates to roughly 500–1,000 conversions depending on engine.

Pricing: Roughly $3 per 1K PDFs on the standard Chromium engine, dropping to ~$1 per 1K at high volume. wkhtmltopdf is cheaper still but the engine is unmaintained and shows its age.

SDKs: Node.js, Python, C#, PHP, Ruby. All are thin.

Fidelity: Whatever Chromium gives you, minus a bit — Api2Pdf runs slightly older Chromium versions to keep costs down. Fine for content pages, sometimes shaky on cutting-edge CSS.

Gotchas: Occasional latency spikes when Lambda cold-starts. Historically has had scattered downtime incidents (check their status page before betting a business on it). Support is thinner than PDFcrowd or PDFShift.

Use when: You're cost-sensitive, doing high volume, and can tolerate the occasional flakiness. Not the choice for critical single-request workflows where a 500 error means a broken user experience.

Prince (self-hosted)

Prince XML is the rendering engine behind DocRaptor. You can license it and run it yourself — either as a command-line binary or via their prince-books daemon.

Free tier: 30-day trial with a "For non-commercial use, this document was rendered by Prince" banner if you use the free version in production.

Pricing: $3,800 for a perpetual server license (one server). Or $500/year subscription. Site licenses and OEM pricing negotiated.

Deployment: Single binary, runs on Linux/macOS/Windows. Feed it HTML and CSS, get back a PDF. No JavaScript execution by default (Prince 15 added optional JS support), which is a feature — you know exactly what's in your input.

Fidelity: Same as DocRaptor, because it's the same engine. Full CSS Paged Media support, PDF/A, PDF/UA, form fields, cross-references, footnotes, running headers.

Gotchas: License cost is high for small teams — $3,800 is 20 months of DocRaptor at 1K/month. Break-even happens around 25K PDFs/month or where compliance/security requires on-prem processing. No JavaScript execution unless you enable it, which breaks client-rendered content (React apps, dashboards that render via API calls).

Use when: On-prem is required (regulated industries, air-gapped environments), or your volume is high enough that the license pays for itself. See Convert HTML to PDF: Complete Guide for a deeper walkthrough of when Prince's approach differs from Chromium's.

Gotenberg (self-hosted, free)

Gotenberg is the open-source option. It's a Docker container that wraps headless Chromium and LibreOffice behind a clean REST API. You run it, you get an API-compatible service with no per-call cost.

Free tier: All of it. Apache 2.0 license.

Cost: Server costs only. A $6/month DigitalOcean droplet handles ~1,500 PDFs/hour of typical web content. A $12 droplet handles 3-5K/hour. At 50K PDFs/month you're paying ~$6-12 in server costs versus $100–200 with a hosted API — the trade is your ops time.

Deployment: docker run -p 3000:3000 gotenberg/gotenberg:8. That's the entire install. Point it at HTML, get a PDF back. Supports the same rendering options as Puppeteer (viewport, wait conditions, custom headers), plus LibreOffice conversions for .docx, .xlsx, etc.

Fidelity: Chromium-level, same as PDFShift or Api2Pdf. No PDF/A, no PDF/UA, no print-CSS niceties beyond what modern Chromium supports.

Gotchas: You own uptime. You own scaling. You own security patches on the Docker host. Fine if you already run infrastructure; a lot of overhead if PDF generation is your only backend workload. Also: Chromium is memory-hungry — plan for 500MB+ per instance and don't run it on a 512MB VPS.

Use when: You have infrastructure engineers, PDF generation is a meaningful cost line, and you don't need print-CSS fidelity. Also: privacy-sensitive workloads where sending HTML to a third-party API is a non-starter.

Migration snippet (drop-in replacements)

The APIs are similar enough that switching between them is mostly changing an endpoint and an auth header. Here are the equivalent calls in Node.js:

PDFShift:

const res = await fetch('https://api.pdfshift.io/v3/convert/pdf', {
  method: 'POST',
  headers: {
    'Authorization': 'Basic ' + Buffer.from('api:' + API_KEY).toString('base64'),
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ source: '<h1>Hello</h1>' })
});
const pdf = Buffer.from(await res.arrayBuffer());

PDFcrowd (via their SDK):

const pdfcrowd = require('pdfcrowd');
const client = new pdfcrowd.HtmlToPdfClient('username', API_KEY);
client.convertStringToFile('<h1>Hello</h1>', 'out.pdf', (err) => {});

Api2Pdf:

const res = await fetch('https://v2.api2pdf.com/chrome/pdf/html', {
  method: 'POST',
  headers: { 'Authorization': API_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({ html: '<h1>Hello</h1>' })
});
const { FileUrl } = await res.json();

Gotenberg (self-hosted):

const form = new FormData();
form.append('files', new Blob(['<h1>Hello</h1>'], { type: 'text/html' }), 'index.html');
const res = await fetch('http://gotenberg:3000/forms/chromium/convert/html', {
  method: 'POST',
  body: form
});
const pdf = Buffer.from(await res.arrayBuffer());

DocRaptor:

const res = await fetch('https://docraptor.com/docs', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    user_credentials: API_KEY,
    doc: { document_content: '<h1>Hello</h1>', type: 'pdf' }
  })
});
const pdf = Buffer.from(await res.arrayBuffer());

Wrap all of these behind an internal renderPdf(html) function and switching providers becomes a one-file change. Do this from day one, not the day your PDF provider goes down.

If your users are the ones generating PDFs — from within their own browser — an API isn't the right shape at all. A browser extension like Convert Anything to PDF runs on the user's machine, doesn't touch your servers, and doesn't bill you per conversion. For extension-vs-API tradeoffs, see Anything to PDF: Complete Format Guide.

Frequently asked questions

Is there a free HTML to PDF API?

Yes. PDFShift gives 500 conversions/month free with no credit card, PDFcrowd gives 100/month, and Api2Pdf gives $1 in credits (roughly 500–1,000 conversions). If "free" means truly zero-cost, you can also self-host Gotenberg — it's open source under Apache 2.0 and runs in a single Docker container. Server costs will be a few dollars a month for typical hobbyist use. There's no hosted service that offers unlimited free conversions at production volume — the economics don't work, since each PDF costs CPU and memory to render.

What's the cheapest HTML to PDF API?

At scale, Api2Pdf is typically the cheapest hosted option at roughly $1–3 per 1,000 PDFs on their Chromium engine. PDFShift and PDFcrowd get down to $2–3 per 1K at 100K+/month tiers. If you can self-host, Gotenberg on a $6/month VPS handles roughly 50,000 PDFs/month, which works out to about $0.00012 per PDF — an order of magnitude cheaper than any hosted service, at the cost of your operational time. For low volume (under 500/month), free tiers are effectively $0.

Which HTML to PDF API has the best CSS support?

DocRaptor (and self-hosted Prince — same engine) has the best print CSS support by a wide margin. It handles CSS Paged Media specs properly: named pages, running headers/footers per section, cross-references via target-counter(), footnotes, widow/orphan control, and page-break rules that actually work. Chromium-based services (PDFShift, PDFcrowd, Api2Pdf, Gotenberg) are fine for modern web CSS but silently drop or miscompile print-specific features. If you're rendering a dashboard: any Chromium service. If you're rendering a book, invoice, or tax form: Prince/DocRaptor.

Can I self-host an HTML to PDF service?

Yes, two main options. Gotenberg is open source (Apache 2.0), runs as a Docker container, and wraps Chromium plus LibreOffice behind a clean REST API. It's the easiest self-hosted option — one docker run command and you have an API. Prince is commercial ($3,800 per server license perpetual, or $500/year), but it's the fidelity leader. Break-even versus DocRaptor happens around 25,000 PDFs/month. You can also build your own with Puppeteer or Playwright in a Node.js process, but you'll spend time on things Gotenberg has already solved: font loading, timeout handling, concurrency, memory management.

How do PDFcrowd and DocRaptor compare?

They target different problems. PDFcrowd is a general-purpose Chromium-based API — good for web content, dashboards, simple invoices, at $9/1K starting. DocRaptor is Prince-as-a-service — built for print fidelity (PDF/A, PDF/UA, real form fields, cross-references, print-CSS features Chromium doesn't support), at $15/1K starting. Rendering a marketing page: PDFcrowd is 40% cheaper and equivalent quality. Rendering a compliance-graded tax form: DocRaptor is worth 10× the cost because Chromium will silently break page-break rules and PDF/A output isn't available at any Chromium-based service.

Bottom line

The right HTML-to-PDF API depends on volume and fidelity, not brand loyalty. PDFShift is the default for most teams — good free tier, clean API, fair pricing. DocRaptor or Prince is the answer when print CSS or compliance matters. Gotenberg is the answer when per-call cost matters more than ops time. And if your PDFs are being generated by users in their own browsers, don't build an API integration at all — hand them Convert Anything to PDF and skip the whole per-conversion billing model.