Design a template once, then render invoices, contracts, reports and labels straight from your API payload.
Replace Puppeteer · wkhtmltopdf · headless Chrome
The PDF pipeline problem
Your team built a quick "PDF generation" service a year ago. It was supposed to be a two-day MVP. Sound familiar?
Chrome released v138, and your invoices started rendering wrong. Again. A Chromium bump silently shifts page breaks until you redeploy.
Your image is 300 MB bigger because it ships a browser nobody uses interactively. Slower CI, slower deploys, bigger attack surface.
Puppeteer flakiness, wkhtmltopdf font fallbacks, retry queues, signed URLs — maintenance nobody planned for in the roadmap.
Upload to S3, rotate keys, expire URLs, audit access. Quietly a project of its own — and PDFs from last quarter still need working links today.
What shipped last quarter is no longer what's in main. The branded invoice from 2023 has to keep rendering correctly forever.
Last month a customer received a malformed invoice at the worst possible time, and your CEO had to write the apology email.
You wanted a PDF. You got a side project nobody asked for.
The hidden cost
Not the cloud bill — the part that never makes it into a budget line. Let's do the math.
4–8 hours a week × €70/hour × 50 weeks, burned on maintenance instead of product work.
Slower CI/CD, higher hosting bill, larger attack surface — for a browser nobody opens.
Again. Queue backlogs and retry storms happen when customers need their PDFs most.
One malformed invoice to your biggest customer is worth more than a year of "engineering savings".
The time your dev spent debugging Puppeteer is time not spent on the product your customers actually pay for.
A managed PDF API costs $29/month. You do the math.
Built for production documents
Invoices·Contracts·Reports·Shipping labels·Certificates·Receipts·Policy documents·Quotes & estimates·Tickets & passes
Invoices, contracts, reports, labels: production-ready, branded, versioned, served from a stable API instead of a Chromium worker pool.
Why developers choose Airpdf
Stop shipping Chromium with your backend. Two of these do the convincing; the rest are simply true.
01 · The whole point
No Chrome to ship, patch or restart. No Chromium layer in your image, no worker pool to babysit, no page-break regression the morning after a Chromium bump. We run the renderer; you call the endpoint.
POST /api/v1/render Authorization: Bearer atl_live_… → 200 OK · application/pdf · 18 KB · 412 ms
02 · Who edits what
A visual editor with pages, containers, text, images and lists — so a header change is a design task again, not a pull request. Templates are versioned, so last year’s invoice still renders exactly as it did.
invoice-v3.tmpl · A4 · EUR · 2 pages · published
/api/v1/render. Get raw bytes or a signed URL. That is the whole protocol.A row-by-row read on the four ways teams solve this, including where Airpdf does not pretend to compete.
| Dimension | Roll your own | Generic HTML→PDF | Enterprise vendor | Airpdf |
|---|---|---|---|---|
| Who maintains the renderer | You. Browser updates, Docker weight, retry queues, signed URLs. | They do. | They do. | We do. |
| Templating model | You build it. | You build it. You send finished HTML. | Included and deep. | Typed, included. |
| Visual editor | You build it. | None. | Usually, at a price. | Included. |
| Pricing shape | Infrastructure plus senior dev time. | Per render. | Per document, plus procurement. | Free tier, then per plan. |
| Time to first PDF | Days to weeks. | Hours. | Months. | Minutes. |
| Best when | The rendering itself is your product. | One-off documents, no templating needs. | Regulated archival, digital signatures at scale. | Documents your product ships every day. |
How it works
Your JSON, in the shape your app already has it.
One POST, one bearer token. That is the whole protocol.
Our renderer does the work. No Chromium in your image.
PDF bytes, a signed URL, or an async webhook.
200 OKapplication/pdf · 18 KB412 ms
Five ready-made templates: invoices, contracts, reports, labels, receipts. Tweak the JSON, hit render, the PDF opens in a new tab. Same engine your production code would hit. Rate-limited to 5 / minute, watermarked, zero account.
Built on open source
Airpdf runs on react-pdf, the open-source React renderer for PDFs maintained by Diego Mura and the community — 25.000+ GitHub stars, seven years of production use.
Every piece of the render pipeline is transparent and auditable.
If you ever want to self-host, your template JSON ports to react-pdf one-to-one. Nothing proprietary in the middle.
25k+ stars and seven years of production use across hundreds of companies — not a template engine we invented last quarter.
We sponsor Diego Mura on GitHub every month. Because the open source we depend on deserves it.
react-pdf powers our default engine — fast, low-overhead, used for 95%+ of renders. Need pixel-perfect HTML+CSS, custom typography or Chromium-style print headers and footers? Our HTML engine is available on Enterprise plans, opt-in per workspace.
Set your volume. Every plan reprices live, and the cheapest one that fits gets highlighted.
Starter
A side project with real customers.
$9/ month
250 PDFs included · $0.015 / extra
Growth
An indie SaaS shipping documents daily.
$29/ month
2,000 PDFs included · $0.010 / extra
Business
A growing SaaS with month-start batches.
$49/ month
5,000 PDFs included · $0.006 / extra
Try the API with 5 templates and 1 API key. PDFs carry a “Made with Airpdf” footer.
50 PDFs included
Priority render queue and 100 GB storage for high-volume products.
15,000 PDFs included · $0.004 / extra
Past 50k PDFs a month: custom volume pricing, unlimited templates, and the HTML rendering engine, which is Enterprise-only. Talk to us →
50,000+ / mo
Create a workspace, design a template, and render a production PDF from your own payload. Minutes, not a sprint.
Free tier · No credit card · SDKs for Node, Python, Ruby and Go