Precision over breadth.

01What 21pdf is

A REST API that accepts HTML, a URL, or a fragment, renders it through headless Chromium, and returns a PDF. Submission is asynchronous — the worker pool keeps the HTTP surface fast. Every PDFOption maps to a field in the Go source at internal/workers/pdf_engine.go; if it's not in that file, it's not a feature we claim on this site.

02Why Chromium-only

The previous engine was wkhtmltopdf, which has stopped receiving upstream work and has limp support for modern CSS (flex, grid, modern units). In April 2026 we removed it — every conversion now goes through Chromium. This kept the codebase simpler, removed a class of CSS drift bugs, and aligned the engine with the browser your customers will render the output in.

03What 21pdf deliberately isn't

21pdf doesn't ship an SDK for Node/Python/Go yet — the API is small enough that raw HTTP is a fair starting point. There's no multi-region rendering (one VM, one country). There's no outbound webhook delivery for job completion; clients poll /v1/jobs/:id instead. These are deliberate omissions — adding them would be dishonest until they're backed by real uptime and real operators.

If it isn't in the code, it isn't on the site. If the site says it ships, it ships.

04Who it's for

Engineers building document workflows: invoices, statements, receipts, reports, shipping labels, compliance exports. The kind of workloads where a page miscount or a rogue redirect is a production incident. That's why 21pdf runs a two-layer SSRF check (HTTP boundary + Chromium request interceptor) instead of one, and why failed jobs do not count toward your quota.

05Billing, honestly

Plans live in code at internal/billing/plans.go and are seeded into Postgres on boot. Razorpay hosted checkout handles PAN so our PCI scope stays at SAQ A. Failed payments get a 7-day grace window with day 1/3/5 nag emails before the account moves to Free. Upgrades are immediate and prorated; downgrades take effect at cycle end.

Get an API key → Read the docs