DocRaptor alternatives — 5 options and when each wins in 2026

DocRaptor is a solid product with an unusual price point. It runs Prince XML — a commercial typesetting engine used by publishers — which makes it best-in-class for typography and significantly more expensive than Chromium-based alternatives. If you’re here, you’ve probably found yourself on the “more expensive than I want” side of that tradeoff.

This post lays out the alternatives honestly: where they’re cheaper, where they’re weaker, and how to decide.

Why you’re leaving DocRaptor

Usually one of these:

1. Price at volume

DocRaptor pricing (2026):

Plan	PDFs/month	Price
Hobby	125	$19
Basic	1,250	$49
Professional	5,000	$99
Business	15,000	$199
Enterprise	50,000+	Custom

At 10,000 PDFs/month, you’re on the $199 Business tier. Chromium-based alternatives (21pdf, PDFShift, PDFCrowd) all offer the same volume at $29/month — a 7× difference.

If you genuinely use Prince-specific features, the premium is justified. Most teams using DocRaptor for invoices or reports don’t, and discover this when they audit their usage.

2. Prince-specific CSS you no longer need

Maybe you started with Prince when modern Chromium didn’t have good @page support. That’s changed. Chromium in 2026 handles:

• @page { size: A4; margin: 20mm }
• @media print with print-colour-adjust
• Page-break properties (break-inside: avoid, etc.)
• CSS counters (in body content, though not in @page margin boxes)
• Orphans and widows

The gap where Prince still wins:

• @page margin boxes (@top-left { content: counter(page); }) — Prince only
• Fine-grained running header/footer content via CSS Paged Media — Prince only
• Advanced typography (true small caps, complex OpenType, fine kerning) — Prince is better
• Footnotes via CSS float: footnote — Prince only

For invoices, reports, certificates, statements — all Chromium-handled well. For book typesetting, legal document production, scientific publishing — Prince still wins.

3. DX issues

Some teams hit specific friction points:

• DocRaptor’s API is sync-only by default (async is opt-in)
• Error messages can be terse
• Pricing tiers jump sharply (125 → 1,250 is a 10× step)

For context, DocRaptor’s support is widely regarded as excellent. These aren’t dealbreakers; they’re tradeoffs.

4. Consolidating vendors

Some teams reduce vendor count when possible. Moving PDF generation to a vendor you’re already using (or one with a lower entry price that’s easier to approve) simplifies procurement.

The alternatives

21pdf

Full disclosure: this is our product. I’ve tried to keep the comparison fair; see the broader 2026 comparison for the more detailed scorecard.

Pricing (USD, net of tax):

• Free: $0 / 100 PDFs/mo
• Starter: $9 / 1,000 PDFs/mo
• Pro: $29 / 10,000 PDFs/mo
• Business: $69 / 50,000 PDFs/mo

Vs DocRaptor at 10k/month: $29 vs $199 (7× cheaper).

Engine: Chromium-only, patched within 7-14 days of upstream.

Features:

• POST /v1/convert with html, url, or simple_html inputs
• Async job model (submit → poll → download). No sync-binary mode.
• SSRF two-layer defence (HTTP boundary + Chromium request interceptor)
• Quota + concurrency gates with distinct 402 / 429 codes
• CSS @page support
• wait_for_network_idle option

Doesn’t ship:

• SDKs for any language (REST-only, intentional for v1)
• PDF encryption, watermarks, digital signing (DocRaptor has all three)
• Outbound webhooks for job completion (poll instead)
• Multi-region rendering

Pick 21pdf if: price matters, SSRF hardening is a concrete requirement, you’re OK with raw REST. Skip if: you need Prince-specific typography, you need an SDK in your stack today.

PDFShift

Pricing:

• Free: $0 / 50 PDFs/mo
• Starter: $9 / 500 PDFs/mo
• Basic: $29 / 10,000 PDFs/mo (same entry as DocRaptor Professional for 2× the volume)
• Premium: $69 / 50,000 PDFs/mo

Engine: Chromium, recent versions.

Features:

• Typed SDKs for Node, Python, Ruby, PHP, Go, .NET
• Sync-first API (async optional)
• @page support, network-idle wait, selector wait, JS expression wait
• Outbound webhooks
• S3 / GCS / R2 direct upload
• PDF encryption, watermarks

Pick PDFShift if: SDK ergonomics are a priority, you want multi-region rendering, you need webhooks. The default Chromium-API choice for US/EU teams in my view — 6 years in market with a strong public track record.

PDFCrowd

Pricing:

• Free: 100 PDFs/mo
• Production: $29 / 15,000 PDFs/mo
• Business: $49 / 45,000 PDFs/mo
• Enterprise: Custom

Engine: Chromium, versioning not publicly detailed (ask).

Features:

• SDKs for Node, Python, Ruby, PHP, Go, Java, .NET, C++
• Sync-first
• @page support
• PDF encryption, watermarks
• ~15 years in market

Pick PDFCrowd if: you want conservative, established, no-surprises. Not the flashiest option; reliably the same for a very long time.

API2PDF

Pricing:

• Pay-per-PDF: ~$0.004/PDF on Chromium path
• Monthly plans available but focused on pay-per-use

Engine: Multi-engine router — can route to Puppeteer (Chromium), LibreOffice, or wkhtmltopdf depending on the request.

Features:

• Multi-engine selection
• Webhooks
• S3 upload
• SDK coverage inconsistent

Pick API2PDF if: you specifically need engine flexibility (rare), you have legacy wkhtmltopdf HTML, or your volume is spiky and pay-per-PDF is cleaner than subscription. Skip if: you want a single consistent product experience.

Prince (self-hosted)

If you’re leaving DocRaptor but you genuinely use Prince-specific features, you can self-host Prince:

• Licence: $3,800-$5,000/server/year (standard commercial)
• Runtime: CLI binary, Java API, or Node/.NET wrappers
• Deployment: single binary per server; you manage the process pool

Pick self-hosted Prince if: your volume justifies the licence fee (break-even vs DocRaptor Business $199/mo is ~20 months; at Enterprise-tier pricing break-even is much faster). You have engineering capacity to operate it. You specifically need Prince output.

For a publishing house or legal-document service at scale, self-hosted Prince is often cheaper than DocRaptor and gives you full control. For a typical SaaS rendering invoices, Chromium-based alternatives are the correct answer.

Decision framework

Walk through these in order:

1. Do you actually need Prince XML’s typography?

Most teams say yes initially, then audit their CSS and find the answer is no. Test: do your templates use any of these?

• @page { @top-left { content: ... } } (page margin-box content)
• float: footnote
• string-set + string() for running headers
• leader() function
• target-counter() for cross-references
• Fine kerning-pair adjustments

If yes to any → stick with DocRaptor or self-host Prince. If no to all → migrate to a Chromium-based API.

2. What’s your volume?

Volume	Best alternative
< 100 PDFs/mo	Any free tier works — DocRaptor’s own free tier is generous
100-1,000/mo	21pdf Starter ($9) or PDFShift Starter ($9)
1,000-10,000/mo	21pdf Pro ($29) or PDFShift Basic ($29)
10,000-50,000/mo	21pdf Business ($69) or PDFShift Premium ($69)
50,000+/mo	Negotiate custom rate with any vendor, or self-host

3. What’s your stack?

• Node-heavy: any of 21pdf (REST), PDFShift (SDK), PDFCrowd (SDK)
• Python-heavy: same, plus note PDFShift and PDFCrowd have maintained Python SDKs
• Serverless (Lambda, Workers): managed API strongly preferred over self-host
• Internal/self-hosted: Gotenberg or Puppeteer over any API

4. What’s your operational appetite?

Managed API if you want a fetch call and done. Self-host if you want control and your team has browser-infrastructure skills.

Migration checklist

If you’ve decided to move off DocRaptor, here’s a safe migration path:

Week 1: parallel render

Keep DocRaptor live. Add the new vendor (e.g. 21pdf) in parallel:

// Feature-flagged parallel render
async function renderInvoice(html: string): Promise<Buffer> {
  if (process.env.PDF_VENDOR === 'docraptor') {
    return renderViaDocRaptor(html);
  }
  if (process.env.PDF_VENDOR === 'qpdf') {
    return renderViaQpdf(html);
  }
  throw new Error('unknown PDF_VENDOR');
}

Week 2: sample comparison

Render 50-100 production invoices via both vendors. Compare byte-for-byte (or visually, if the bytes differ). Flag any templates that look wrong on the new vendor.

Week 3: fix divergences

Common fixes when moving from Prince to Chromium:

• Replace @page { @top-left { content: ... } } with the vendor’s header_template option (Chromium-based APIs expose this)
• Replace float: footnote with fixed-positioned footer elements
• Replace Prince’s leader() with CSS border-bottom: 1px dotted
• Test print colours — may need print-color-adjust: exact

Week 4: traffic ramp

5% → 25% → 100% over the week. Keep DocRaptor as the fallback in case of vendor issues.

Week 5: deprecate

Cancel DocRaptor subscription. Keep the code path for 30 days in case you need to revert.

If you’re keeping DocRaptor

If after reading this you’ve decided DocRaptor is the right fit — that’s a legitimate choice. You’re buying Prince XML output, which is a defensible decision for publishing, legal, scientific, and other print-quality use cases.

Tips for using DocRaptor efficiently:

• Use the async mode — saves HTTP-connection overhead
• Cache rendered PDFs aggressively (invoices are immutable; don’t re-render)
• Use test keys (YOUR_API_KEY_HERE) during dev — they’re free, unlimited, and watermarked
• Look at their Prince-specific CSS guides; you’re paying for features that deserve usage

Closing

DocRaptor is priced for the Prince XML output it delivers. If you genuinely use Prince’s typography, it’s fairly priced. If you don’t, you’re paying a 5-10× premium for a Chromium-equivalent render.

Audit your templates first. If none of the Prince-specific features are load-bearing, migrate — the engineering work is a week or two, the savings accumulate forever.

For a deeper scorecard across all the options, see the 2026 comparison. For the architecture decision between managed APIs and self-hosting, see library vs API.

— 21pdf Engineering