PDFShift is one of the better HTML-to-PDF APIs in 2026. If you’re here, it’s usually because you want a specific feature they don’t ship, you want a different async model, or you’re evaluating alternatives for procurement reasons.
This post compares the credible options fairly.
TL;DR
- PDFShift is already well-priced ($29/10k) for a Chromium-based API. Most “cheaper” alternatives aren’t actually meaningfully cheaper.
- 21pdf — $29/10k, async-first, cleaner REST surface. The strongest direct alternative.
- PDFCrowd — $29/15k, older and more conservative. A fit if you want boring.
- DocRaptor — Prince XML engine, premium pricing. Different market (typography).
- API2PDF — pay-per-PDF, multi-engine. For legacy wkhtmltopdf or spiky volume.
- Self-hosted Gotenberg / Puppeteer — worth it past 100k PDFs/day, not below.
Why leave PDFShift?
PDFShift is good. Reasons you might still move:
1. You want async-first
PDFShift returns the PDF in the HTTP response by default. Async (webhook or poll) is available but opt-in. For high-volume or unpredictable render times, async-first is a nicer default — it decouples your HTTP surface from Chromium’s render time.
21pdf is async-only by design. Gotenberg (self-hosted) can be either. DocRaptor is sync-first but has good async support.
2. You want a specific feature PDFShift doesn’t ship
- PDF/A-3 output with embedded XML (Factur-X, ZUGFeRD e-invoicing) — Prince XML only; use DocRaptor or self-hosted Prince
- Prince-specific typography (margin boxes, string-set, running headers) — DocRaptor
- Multi-engine flexibility (route to wkhtmltopdf legacy, LibreOffice) — API2PDF
- Full data residency control (EU-only guaranteed at infra level) — self-host
3. Procurement / consolidation
Some companies require redundant vendors; others prefer fewer. If PDF rendering is peripheral, consolidating to a vendor you already use (e.g. if you’re heavy on AWS and want API2PDF on top of existing AWS billing) is a valid reason.
4. DX preference
PDFShift’s SDKs are excellent. If your team prefers raw REST (no SDK install, no dependency updates), alternatives that lean that way (21pdf, most self-hosted paths) feel cleaner.
The alternatives
21pdf
Pricing (USD, net):
- Free: $0 / 100 PDFs/mo
- Starter: $9 / 1,000
- Pro: $29 / 10,000 — same as PDFShift Basic
- Business: $69 / 50,000
Vs PDFShift at 10k/month: identical price.
Where 21pdf differs from PDFShift:
- Async job model as the default (not opt-in)
- REST-only (no SDKs shipped yet); PDFShift has typed SDKs for Node, Python, Ruby, PHP, .NET, Go
- Two-layer SSRF publicly documented
- Single-region (PDFShift has multi-region)
Pick 21pdf if: you prefer async-first, you don’t need an SDK today, and you want SSRF hardening explicitly documented. Don’t pick if SDK ergonomics in your stack matter more than REST simplicity.
PDFCrowd
Pricing:
- Free: 100 PDFs/mo
- Production: $29 / 15,000 PDFs/mo (50% more volume than PDFShift at the same price)
- Business: $49 / 45,000 PDFs/mo
Engine: Chromium.
Where PDFCrowd differs from PDFShift:
- Oldest vendor in the market (~15 years); more conservative aesthetic
- SDK coverage across 10+ languages, including Java and C++ (PDFShift has 6)
- Less flashy; release cadence slower; no multi-region
- Sync-first (same as PDFShift)
Pick PDFCrowd if: you want a long operational track record and extensive SDK coverage. Default “boring, reliable” choice.
DocRaptor
Pricing:
- Hobby: $19 / 125 PDFs/mo
- Pro: $99 / 5,000 PDFs/mo
- Business: $199 / 15,000 PDFs/mo
Engine: Prince XML (not Chromium).
Where DocRaptor differs: completely different rendering engine. Best typography, best @page margin-box support, significantly more expensive. Covered in depth in the DocRaptor alternatives post — short version: only pick DocRaptor if you specifically need Prince-output quality.
API2PDF
Pricing: ~$0.004/PDF on Chromium path (pay-per-use). Monthly plans exist but aren’t the primary offering.
Engine: multi — Puppeteer, wkhtmltopdf, LibreOffice.
Pick API2PDF if: pay-per-PDF pricing suits your billing model, you need legacy wkhtmltopdf compatibility, or you want engine flexibility. Skip for steady-state high volume — flat subscriptions beat pay-per-PDF once volume is predictable.
Self-hosted (Gotenberg / Puppeteer)
Not really an “alternative” at modest volume. Below ~100k PDFs/day, managed APIs are cheaper all-in than the engineering cost of running your own Chromium pool.
Past 100k/day it starts to make sense — the library-vs-API post has the cost model.
Feature matrix
What each vendor actually ships, at the time of writing:
| Feature | PDFShift | 21pdf | PDFCrowd | DocRaptor | API2PDF |
|---|---|---|---|---|---|
| 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 | ✓ | ✓ | ✓ | ✓ | ✓ |
| SSRF Chromium interceptor | ✓ | ✓ | ? | n/a | ? |
| Outbound webhooks | ✓ | — | — | ✓ | ✓ |
| Signed URL delivery | ✓ | — | ✓ | ✓ | ✓ |
| S3 / GCS / R2 direct upload | ✓ | — | ✓ | ✓ | ✓ |
| PDF encryption | ✓ | — | ✓ | ✓ | ✓ |
| Watermarking | ✓ | — | ✓ | ✓ | — |
| Multi-region render | ✓ | — | — | ✓ | ✓ |
| Node SDK | ✓ | — | ✓ | ✓ | ✓ |
| Python SDK | ✓ | — | ✓ | ✓ | ✓ |
| Go SDK | ✓ | — | ✓ | ✓ | — |
| Ruby SDK | ✓ | — | ✓ | ✓ | — |
| Free tier | 50/mo | 100/mo | 100/mo | 125/mo | 100 trial |
21pdf has the fewest ticked boxes because we’ve shipped a narrow product well rather than a broad product thinly. Everything we don’t ship is explicitly labelled roadmap rather than half-working.
Pricing head-to-head
At typical SaaS volumes:
| Volume | PDFShift | 21pdf | PDFCrowd | DocRaptor | API2PDF |
|---|---|---|---|---|---|
| 50/month | Free | Free | Free | Free | Free |
| 500/month | $9 | $9 | Free | $19 | ~$2 |
| 5,000/month | $29 | $29 | $29 | $99 | ~$20 |
| 10,000/month | $29 | $29 | $29 | $149 | ~$40 |
| 50,000/month | $69 | $69 | $49 | Custom | ~$200 |
| 100,000/month | Custom | Custom | Custom | Custom | ~$400 |
Key observations:
- At 10k PDFs/month, PDFShift and 21pdf are tied; PDFCrowd is tied; DocRaptor is 5× more expensive.
- At 50k PDFs/month, PDFCrowd pulls ahead slightly ($49 vs $69); 21pdf/PDFShift are tied.
- API2PDF wins on very small volumes (pay-per-PDF) and loses on very large (subscription economics).
Migration checklist: PDFShift → 21pdf
If you’re moving specifically to 21pdf, the API shapes are similar but not identical:
Request mapping
{
- "source": "<html>...</html>",
+ "html": "<html>...</html>",
- "sandbox": true,
- "format": "A4",
- "landscape": false,
- "margin": "20mm",
- "wait_for": "body",
+ "options": {
+ "page_size": "A4",
+ "orientation": "portrait",
+ "margin_top": 20,
+ "margin_bottom": 20,
+ "margin_left": 15,
+ "margin_right": 15,
+ "wait_for_network_idle": true
+ }
}
Response shape
PDFShift returns the PDF bytes directly in the response. 21pdf returns a job_id and you poll /v1/jobs/:id then download /v1/jobs/:id/download.
Thin adapter pattern:
interface PdfRenderer {
render(html: string, opts: RenderOptions): Promise<Buffer>;
}
class PdfShiftRenderer implements PdfRenderer { /* ... */ }
class QpdfRenderer implements PdfRenderer { /* ... */ }
const renderer: PdfRenderer = process.env.PDF_VENDOR === '21pdf'
? new QpdfRenderer(process.env.QPDF_KEY!)
: new PdfShiftRenderer(process.env.PDFSHIFT_KEY!);
Keep both alive for a week. Compare outputs. Flip when confident.
Webhooks
If you use PDFShift webhooks today, 21pdf doesn’t ship them yet — you’d switch to polling. Change:
// PDFShift: provide webhook URL, wait for POST back
await pdfshift.convert({ source, webhook: 'https://you.com/pdfs/done' });
// 21pdf: poll until status === 'succeeded'
const { job_id } = await qpdf.convert({ html, options });
while (true) {
const st = await qpdf.jobStatus(job_id);
if (st.status === 'succeeded') break;
if (st.status === 'failed') throw new Error(st.message);
await sleep(500);
}
const pdf = await qpdf.download(job_id);
For internal-only job rendering this is fine. For customer-facing flows where you want push notifications, stick with PDFShift for now.
When PDFShift wins
I’d keep PDFShift if any of the following apply to you:
- You use their SDKs and they work well — rewriting against a new REST client is engineering time with low payoff.
- You rely on webhooks for job-completion push.
- You need selector-based or JS-expression waits beyond network-idle.
- You need multi-region rendering.
- Your team values “mid-tenure vendor with strong public track record” — PDFShift has 6+ years of operations data.
PDFShift is the default “US/EU price-sensitive” pick I’d recommend to anyone not actively looking for a specific feature gap.
When to consider 21pdf
- You want an async-first API by default.
- You specifically want SSRF two-layer defence documented in the vendor’s public materials.
- You’re OK with REST-only (no SDKs yet).
- You want a vendor shipping quickly — 21pdf is newer and the roadmap is active (see the changelog).
- You want to support a small vendor on purpose.
These are real reasons; they’re narrower than “it’s cheaper” because 21pdf and PDFShift are identically priced at the Pro tier.
Try 21pdf alongside PDFShift
100 PDFs/mo free, same $29 price point as PDFShift at 10k/mo. Async-first REST. No SDK needed — 40 lines of any HTTP client.
Closing
PDFShift doesn’t have many true competitive weaknesses. The “leave PDFShift” decision is usually about specific missing features (async default, SSRF documentation, aesthetic preference) rather than price or quality.
If one of those specifics applies, 21pdf is the direct replacement at the same price point. If not, save yourself the migration and stay on PDFShift.
For the full 5-vendor scorecard across Engine / SSRF / API / DX / Pricing / Ops dimensions, see the 2026 comparison.
— 21pdf Engineering