The best HTML to PDF API in 2026 — honestly compared

I’ve spent the last three years building 21pdf — an HTML-to-PDF API — and the eighteen months before that running document infrastructure inside a larger SaaS. In that time I’ve talked to engineers evaluating this market weekly, read every competitor’s docs, integrated with most of them, and filed bug reports against a few.

This is the comparison I wish existed before I started. It names specific strengths and weaknesses of specific vendors, based on real evaluation rather than marketing copy. It scores my own product against the others on the same dimensions. And — because I think this is where most comparisons fail — it’s honest about which API you should pick instead of 21pdf in particular circumstances.

How this comparison is scored

Every HTML-to-PDF API claims every feature. Claims are cheap. This comparison scores six things I’ve actually verified by integrating or reading source:

1. Rendering engine quality — Chromium version, Prince, or something else; how often patched
2. SSRF hardening — documented defence layers, CVE history
3. API ergonomics — auth, request shape, error codes, async model
4. DX — SDK coverage, docs quality, error messages, onboarding speed
5. Pricing transparency — inspectable pricing page, predictable costs, over-quota behaviour
6. Operational reality — uptime history, support responsiveness, ticket close rate

Each vendor gets a 1-5 score on each dimension. The total is out of 30. No dimension is weighted — I don’t trust composite scores where the author picks the weights.

The scorecard (at a glance)

API	Engine	SSRF	API	DX	Pricing	Ops	Total
21pdf	4	5	5	3	5	3	25
PDFShift	4	4	5	5	5	4	27
DocRaptor	5	4	4	5	3	5	26
API2PDF	3	3	4	3	4	3	20
PDFCrowd	3	3	4	3	4	4	21

(Prince XML self-hosted is not scored because it’s not comparable — it’s software you run, not an API.)

Yes, I scored PDFShift higher than my own product. The DX and operational track record advantages they have from six years in-market are real. 21pdf is 2026-vintage; we’ll close those gaps, but you should know the state today.

Now the detail.

21pdf

The shortest sell: SSRF-hardened, async-first HTML-to-PDF API with flat-rate monthly subscriptions. Free tier: 100 PDFs/month. Paid plans $9 to $69/month.

What 21pdf is actually good at

• SSRF defence in depth. Two-layer check — HTTP boundary and Chromium request interceptor. Documented at /features. Most competitors publicly document only one layer.
• Async job model as the default. No 30-second HTTP connection hold — submit, poll, download. Scales cleanly to batch workloads without clients holding long-lived connections.
• Flat pricing, hard 402 on overage. No surprise bills. You know exactly what you’ll pay.
• Aggressive pricing. $9 Starter for 1k PDFs/mo undercuts every comparable tier in this list. The free tier (100/mo) is larger than several competitors’ too.
• Honest feature gates. Every plan has every API feature. Plans gate throughput, not capability.
• Chromium-only. Dropped wkhtmltopdf in April 2026. No legacy engine to explain.

Where 21pdf is weaker

• No SDKs yet. Raw REST only. 40-line Node/Python integrations are easy (see the guide) but a typed SDK would be nicer.
• No multi-region. Single VM deployment today. Doesn’t matter for most customers but does if your workload is latency-sensitive to a distant region.
• No outbound webhooks. Clients poll. Fine for most cases but a missing feature for event-driven architectures.
• No PDF encryption / watermarks / digital signing. Roadmap, not shipped.
• Younger operational track record. 21pdf is a 2026 product; DocRaptor has a decade of uptime data behind it.

When to pick 21pdf

• Price is a top-three criterion — the $9 Starter and $29 Pro tiers undercut most comparable options.
• SSRF hardening is a concrete requirement (enterprise contracts, healthcare data, financial flows).
• You want predictable subscription pricing with hard quota enforcement.
• Your integration is comfortable with raw REST and async polling.

When not to pick 21pdf

• You need an SDK in your stack language today.
• You need multi-region rendering for latency reasons.
• You need outbound webhook delivery for job completion.
• You need PDF encryption or digital signing (use Prince/DocRaptor).

PDFShift

The shortest sell: Clean, well-documented, Chromium-based HTML-to-PDF API with the best SDK coverage in this comparison. USD-priced, Europe-based.

Scored dimension by dimension:

• Engine (4/5): Chromium, patched roughly in line with upstream. No unusual bugs in my integration testing.
• SSRF (4/5): Documents a private-IP block at the HTTP layer and a Chromium request interceptor. Haven’t personally verified the DNS-rebinding edge case but their public stance is solid.
• API (5/5): Single /v2/convert endpoint, sync response by default, async available. Clean error shapes. Consistent across languages.
• DX (5/5): Typed SDKs for Node, Python, Ruby, PHP, .NET, Go. Each SDK is maintained (recent commits, reasonable issue close rate). Docs are clear and include working sandbox curl.
• Pricing (5/5): Pricing page is a table; overage behaviour is documented; annual discount is real.
• Ops (4/5): Public status page, historical uptime > 99.9%. Support via email, responsive in my tests.

When to pick PDFShift

• Default choice if you’re in the US/EU, price-sensitive, and want SDK ergonomics.
• You want a vendor with six years of operational track record.
• Your team is opinionated about typed SDKs per language.

When not to pick PDFShift

• You need specific SSRF reassurance beyond what’s publicly documented — ask directly.
• You need print-shop-quality typesetting (use DocRaptor/Prince).
• You need an SDK in your stack language today (21pdf is REST-only, PDFShift has typed SDKs).

DocRaptor

The shortest sell: The only credible API running Prince XML. Best-in-class typesetting; priced accordingly.

• Engine (5/5): Prince XML, which is in a category of its own for typography. Kerning, ligatures, small caps, running heads with proper counter injection — all handled correctly and consistently.
• SSRF (4/5): Documented two-layer checking. Prince itself does less of the fetching (DocRaptor’s infrastructure handles it), so the attack surface differs from Chromium-based competitors.
• API (4/5): REST-ish, sync-only by default (async via polling is available). The response shape is old-school (field names like javascript: "true" as strings rather than booleans) but works.
• DX (5/5): Docs are comprehensive, with an entire section dedicated to Prince-specific CSS. SDKs for Ruby, Python, PHP, Node, .NET, Go. Support is legendary for a small team.
• Pricing (3/5): Significantly more expensive than Chromium-based APIs. $19/month for 125 PDFs; $99/month for 1,250. Pay-per-PDF overages. Justifiable for typesetting, hard to justify for invoices.
• Ops (5/5): Public status page, multi-year uptime track record > 99.99%. Best-in-class.

When to pick DocRaptor

• You’re a publisher, law firm, or design-heavy workflow where layout must be perfect.
• Your output is legally or contractually bound to specific typographic features.
• Price is not the top-three concern.

When not to pick DocRaptor

• You render standard business documents (invoices, reports, statements). Chromium renders these indistinguishably, cheaper.
• Your volume is high (>10k/month). Prince’s per-document cost doesn’t scale gently.

API2PDF

The shortest sell: A multi-engine aggregator — routes your request to Chromium (Puppeteer), wkhtmltopdf, or LibreOffice behind one API. Pay-per-PDF pricing.

• Engine (3/5): The aggregator model means you can pick; it also means none of the engines get as much engineering love as a single-engine vendor. wkhtmltopdf support in particular is a legacy thing, not a reason to choose this vendor in 2026.
• SSRF (3/5): Publicly documents HTTP-layer blocking. Haven’t seen specific Chromium-interceptor detail. Ask them directly if SSRF matters to you.
• API (4/5): REST, reasonably consistent. Multiple endpoints per engine, which becomes confusing; you have to know whether you’re calling Puppeteer or wkhtmltopdf before you pick the URL path.
• DX (3/5): SDKs exist but are sparsely maintained. Docs are adequate but skew toward example code over reference material.
• Pricing (4/5): Pay-per-PDF at ~$0.004. Predictable if your volume is predictable; spikey if not.
• Ops (3/5): Status page available. Uptime is fine; support response time is longer than average.

When to pick API2PDF

• You genuinely want to swap rendering engines without re-integrating (rare requirement).
• Pay-per-PDF suits your billing model (low, spiky volume).
• You have legacy wkhtmltopdf HTML and can’t migrate off it.

When not to pick API2PDF

• You want a single, consistent product experience. The multi-engine model is a tax.
• Volume is predictable and high. Flat subscriptions beat pay-per-PDF at steady-state.

PDFCrowd

The shortest sell: The old reliable. Oldest player in this market, Chromium-based, utilitarian.

• Engine (3/5): Chromium, but documentation about version is sparse. Ask them.
• SSRF (3/5): HTTP-boundary blocking documented. Chromium-layer details not public.
• API (4/5): REST, sync-first, works. Error messages could be better.
• DX (3/5): SDKs for ~10 languages, variable maintenance quality. Docs are functional but dated-looking.
• Pricing (4/5): Subscription plans from $29/month to $249/month. Over-quota billing per-PDF.
• Ops (4/5): Been around since ~2010. Stable. Not fancy. Public status unclear.

When to pick PDFCrowd

• You want boring, reliable, and to not think about it again.
• You’re replacing an older PDFCrowd integration and don’t want to change vendors.

When not to pick PDFCrowd

• You care about best-in-class anything. PDFCrowd is workmanlike, not exceptional.
• You want a modern API aesthetic and fast-moving vendor.

Prince XML (honourable mention)

Prince isn’t an API — it’s a binary you install on a server and invoke via CLI or library. For the teams it suits (publishers, legal typesetters, corporate finance reports), it’s unrivalled. Licensing is per-server and runs $3,800+ per CPU; it’s not a SaaS substitute for most teams.

If you’re building something where typesetting quality is the product (a book publisher, a legal-document service, a print-on-demand business), Prince is worth knowing. Everyone else should use a Chromium-based API and be done with it.

The feature matrix

Pulling together what I’ve verified for each vendor:

Feature	21pdf	PDFShift	DocRaptor	API2PDF	PDFCrowd
Chromium engine	✓	✓	— (Prince)	✓ (option)	✓
Prince engine	—	—	✓	—	—
wkhtmltopdf engine	—	—	—	✓ (legacy)	—
CSS @page	✓	✓	✓	✓	✓
Network-idle wait	✓	✓	✓	✓	✓
Selector wait	—	✓	✓	✓	✓
JS expression wait	—	✓	—	✓	—
Async job model	✓ (default)	✓ (opt-in)	✓ (opt-in)	✓ (opt-in)	—
SSRF HTTP-layer block	✓	✓	✓	✓	✓
SSRF Chromium interceptor	✓	✓	n/a (Prince)	?	?
Outbound webhooks	—	✓	✓	✓	—
Signed URL delivery	—	✓	✓	✓	✓
S3/GCS direct upload	—	✓	✓	✓	✓
PDF encryption	—	✓	✓	✓	✓
Watermarking	—	✓	✓	—	✓
Digital signing	—	—	✓	—	—
Multi-region render	—	✓	✓	✓	—
Node SDK	—	✓	✓	✓	✓
Python SDK	—	✓	✓	✓	✓
Go SDK	—	✓	✓	—	✓
Ruby SDK	—	✓	✓	—	✓
PHP SDK	—	✓	✓	—	✓
.NET SDK	—	✓	✓	—	✓
Free tier	20/mo	50/mo	125/mo	100/mo (trial)	100/mo
VAT/sales-tax invoice	✓	✓	✓	✓	✓
Aggressive entry price ($9)	✓	—	—	—	—

21pdf has the fewest ✓s because we’ve chosen to ship a narrow product well rather than a broad product badly. Every feature we don’t list above is explicitly on the roadmap in our changelog rather than quietly half-working in production.

Pricing head-to-head

Using “10,000 PDFs per month” as the reference volume (typical mid-stage SaaS):

Vendor	Monthly cost	Cost / PDF
21pdf Pro	$29	$0.0029
PDFShift (Medium)	$29	$0.0029
PDFCrowd (Production)	$49	$0.0049
DocRaptor (Pro)	$149	$0.0149
API2PDF	~$40 (pay-per-PDF at $0.004)	$0.004

21pdf is cheapest by a small margin; PDFShift is a virtual tie. DocRaptor is 5× more expensive because you’re paying for Prince.

Below 1,000 PDFs/month, everything’s free-tier noise. Above 100,000/month, everyone will negotiate a custom deal and the list price stops meaning much.

Operational track record

This is where young products (including 21pdf) pay a tax. At time of writing:

• DocRaptor: ~10 years in market, 99.99% historical uptime (public SLA).
• PDFCrowd: ~15 years in market, no public SLA number but general availability is high.
• PDFShift: ~6 years in market, 99.9% historical uptime on public status page.
• API2PDF: ~5 years in market, intermittent status-page updates.
• 21pdf: <1 year in production. Transparent changelog, but no meaningful 12-month uptime data yet.

If operational track record is a top-three criterion, DocRaptor and PDFShift are the safer picks. 21pdf will earn that track record over the next 12-24 months; I’m not asking you to trust it today.

Decision framework (who should pick what)

Pick 21pdf if:

• Price is a top-three concern — $9 Starter / $29 Pro undercut every comparable tier.
• SSRF hardening is a stated enterprise requirement.
• You want flat predictable pricing with hard 402 on overage.
• Your integration is comfortable with raw REST and async polling.

Pick PDFShift if:

• You’re in the US/EU and price-sensitive.
• SDK ergonomics in your stack language matter.
• You want a mid-tenure vendor with a strong public track record.
• You need multi-region rendering.

Pick DocRaptor if:

• Typesetting quality is a product requirement (publishing, legal, fine print).
• Your volume is low-to-medium (under 5,000/month) where the premium doesn’t bite.
• You need advanced typography features Chromium can’t replicate (small caps, true kerning, complex running heads).

Pick API2PDF if:

• You specifically want engine flexibility.
• You have legacy wkhtmltopdf HTML you can’t migrate.
• Pay-per-PDF pricing suits your billing model.

Pick PDFCrowd if:

• You want conservative, established, no-surprises.
• You’re migrating an existing PDFCrowd integration and don’t want to change.

Self-host (Gotenberg, Puppeteer, Prince) if:

• Your volume is > 100k PDFs/day.
• PDF rendering is central to your product.
• You have spare infrastructure engineering capacity.

How to evaluate in practice

If you’re serious about choosing, do this:

1. Sign up for free tiers on 3 candidates. 30 minutes total.
2. Build a minimum-viable integration against each. 2 hours each; identical test HTML, identical assertions.
3. Compare the PDF outputs byte-for-byte. If they’re indistinguishable (they usually are, for standard documents), move to non-rendering dimensions.
4. Compare error responses. Induce a quota exhaustion, an SSRF attempt, a malformed HTML. Good APIs give you useful, structured error bodies. Bad APIs return 500 with a stack trace.
5. Ask support the hardest question you can think of. Response time + quality tells you a lot.
6. Pick the one that felt least bad to integrate. That’s usually right.

Don’t over-optimise. Any of the five APIs I scored above is viable for most workloads. The differences only bite in specific edge cases — and if you have those edge cases, you’ll know.

A word on the “best” framing

Every comparison post ends with “here’s the best”. I resist that framing because it assumes a single buyer with uniform priorities. The market doesn’t have one.

If price-per-PDF is a top-three constraint, 21pdf is legitimately the best fit for you — not because we’re technically superior to PDFShift or DocRaptor (we’re not, on several axes) but because our $9 Starter and $29 Pro tiers undercut every comparable option while the SSRF and architecture work is done properly.

If you’re an enterprise procurement team in the US, PDFShift or DocRaptor are probably safer picks for the operational-track-record reasons above.

If you’re a publisher, DocRaptor is the answer and the others are a distraction.

Use the scorecard above as a structured way to surface your own priorities, not as an ordering you should inherit.

— 21pdf Engineering