You're building a SaaS app and you need to generate PDFs. Invoices, reports, contracts, receipts — something that looks professional and arrives reliably. You search for "PDF generation API", and suddenly you have four or five options with different pricing pages, different feature sets, and zero obvious way to compare them.
This article cuts through that. We look at four tools — Transactional.dev, DocRaptor, PDFShift, and Gotenberg — across the criteria that actually matter when you're making a decision: how you define documents, what it costs, where it runs, and what breaks at scale.
This is not a sponsored comparison. Transactional.dev is one of the tools being compared. We'll be honest about its limitations alongside its strengths.
What to compare
When evaluating a PDF generation API, the questions that matter most are:
- How do you define the document? Raw HTML string, hosted URL, or reusable template with variables?
- Where does it run? Fully managed SaaS or self-hosted on your own infra?
- What does it cost? Per-document, per-month, or compute-based?
- How does it handle dynamic data? Variable injection, loops, conditionals?
- What's the integration surface? Simple REST call, or a library you need to maintain?
- What are the failure modes? Rate limits, cold starts, rendering consistency?
The four tools
Transactional.dev
Transactional.dev is a managed PDF API built around the idea of reusable templates. You design your document using HTML and Tailwind CSS in a browser editor, define variables using Handlebars syntax, and save it as a named template. At generation time, you POST to the API with a documentId (a UUID) and a variables object.
curl -X POST https://api.transactional.dev/v1/generate \
-H "x-api-token: YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"documentId": "1d8e5d56-1a4f-4b62-8c33-2d34a64b2f00",
"variables": {
"customer": { "name": "Acme Corp" },
"invoice": { "number": "INV-2026-0142", "total": 1280.50 }
}
}'
The API returns a signed URL pointing to the generated PDF. No SDK required — just a POST with a JSON body.
What it's good at: The template system is the main selling point. You build once, generate many times. No HTML string assembly in your code, no layout drift between versions, no Puppeteer instance to maintain. The Tailwind support means designers can work in the editor without writing PDF-specific layout code.
Honest tradeoffs: Transactional.dev is newer and smaller than the alternatives. It has fewer native integrations, a smaller ecosystem, and less documentation for edge cases. If you need advanced header/footer pagination control or very complex table-of-contents generation, you may hit limitations. There's no self-hosting option — your templates and generated files live on their infrastructure.
Pricing: There is a free tier. Paid plans are usage-based.
DocRaptor
DocRaptor uses Prince XML under the hood, which is one of the most capable HTML-to-PDF rendering engines available. It handles complex pagination, footnotes, table-of-contents generation, and CSS paged media better than Chromium-based tools. It accepts raw HTML strings or a URL.
What it's good at: Complex document layout. If you're generating 80-page legal contracts with precise header/footer control, footnotes, and chapter numbering, DocRaptor is likely the most capable option. Prince's CSS support for print is excellent.
Honest tradeoffs: The API model is document-in, PDF-out. There's no built-in template system — you assemble the HTML string in your code before sending it. That means layout logic lives in your application, not in a shared document definition. DocRaptor is also one of the pricier options at higher volumes.
Self-hosted: Not available through DocRaptor itself, though Prince XML can be licensed separately and self-hosted.
PDFShift
PDFShift is a Chromium-based HTML-to-PDF API. You send HTML or a URL, it renders it in a headless browser, and returns a PDF. It supports CSS, JavaScript execution, custom headers/footers, and watermarking.
What it's good at: Pixel-accurate rendering of complex CSS, JavaScript-rendered content, and existing web pages. If you have a web page that already looks right in a browser, PDFShift will produce a PDF that matches it closely. It has a clean REST API and reasonable pricing.
Honest tradeoffs: Like DocRaptor, there's no template layer — your code is responsible for building the HTML. If you're generating variations of the same document (invoices for different customers), you're doing string interpolation or server-side rendering on your end before calling the API. Chromium-based rendering can also be slower for large batches compared to layout-engine-based tools.
Self-hosted: No managed self-hosting option, though alternatives like Puppeteer or Playwright can replicate the approach locally.
Gotenberg
Gotenberg is a different kind of tool. It's a Docker microservice that wraps Chromium and LibreOffice, exposing a REST API you run on your own infrastructure. You POST HTML, a URL, or a Word/LibreOffice document, and it returns a PDF.
What it's good at: Self-hosting, cost control at scale, and flexibility. If you're processing thousands of PDFs per day and want to avoid per-document API fees, running Gotenberg on your own cluster makes economic sense. It also handles Office document conversion (.docx to PDF) which none of the others do natively.
Honest tradeoffs: You own the operations. That means container orchestration, scaling under load, monitoring, and updates. Cold start latency on Chromium can be a problem at low-volume or bursty workloads. Like PDFShift, there's no built-in template system — you still manage document construction in your code.
Pricing: Free and open source. You pay for compute.
Comparison table
| Transactional.dev | DocRaptor | PDFShift | Gotenberg | |
|---|---|---|---|---|
| Rendering engine | Chromium-based | Prince XML | Chromium | Chromium + LibreOffice |
| Template system | Yes (Handlebars + Tailwind) | No | No | No |
| Self-hosted | No | No | No | Yes (Docker) |
| Managed SaaS | Yes | Yes | Yes | No |
| Input type | Template + variables | HTML / URL | HTML / URL | HTML / URL / Office docs |
| Office doc conversion | No | No | No | Yes |
| Free tier | Yes | Yes (test mode) | Yes | Free (self-hosted) |
| Complex pagination | Basic | Excellent | Good | Good |
| API simplicity | High | Medium | High | Medium |
| Operational overhead | None | None | None | High |
Which tool fits which situation
Use Transactional.dev if your use case is generating the same class of document repeatedly with different data — invoices, receipts, contracts, certificates, onboarding PDFs. The template-first model pays off when your document structure is stable and your data changes per generation. You don't want PDF layout logic scattered across your codebase.
Use DocRaptor if you're generating complex, paginated documents with precise typographic control — legal documents, academic reports, books. Prince XML's CSS paged media support is substantially better than Chromium for this.
Use PDFShift if you have existing HTML pages or web views that you need to render to PDF faithfully, including JavaScript-rendered content. It's also a reasonable choice if you want a simple per-request API without any upfront template setup.
Use Gotenberg if you need to self-host for cost, data residency, or compliance reasons — or if you need Office document conversion alongside PDF generation. Be prepared to own the operational complexity.
A note on the template gap
The one pattern that separates Transactional.dev from the others is the template layer. Every other tool on this list treats PDF generation as a one-shot rendering task: give us document content, get back a PDF. Transactional.dev treats it as a two-phase workflow: define the document structure once, then pass variables at generation time.
If you've ever maintained a codebase where invoice HTML gets assembled from string templates in three different service files, you'll recognize the problem that solves. The document definition becomes a first-class artifact, versioned separately from the code that calls it.
That said — if you're generating one-off documents with no repeating structure, or if you need self-hosting, the others are better fits.
Conclusion
There's no universal winner here. Each tool was built for a different primary use case:
- Transactional.dev: Template-based recurring documents, managed, simple API
- DocRaptor: Complex paginated documents, precise CSS print support
- PDFShift: Accurate HTML/CSS/JS rendering, existing web pages
- Gotenberg: Self-hosted, cost-efficient at scale, Office conversion
If you're building a SaaS app that generates invoices, reports, or contracts for end users, Transactional.dev's template system keeps document logic out of your application code. You can start on the free tier and generate your first PDF from an HTML template in a few minutes — no infrastructure to configure, no Chromium process to manage.
For everything else, match the tool to the rendering complexity and operational model that fits your situation.