Turning a web page into a PDF and building a document from data sound like one job, but they pull you towards different tools. For HTML you already render, a converter API is quickest. For invoices, certificates and contracts filled from records, a template API saves code. If files can't leave your servers, run a self-hosted engine.
Developers usually arrive at this search with a deadline and one document in mind: an invoice, a monthly report, a signed contract. Whatever you pick ends up in a code path that runs every day, so the decision deserves more than a glance at a homepage demo. The guide below covers the two forks that decide most of it, the mistakes that cost teams a rewrite, what the category costs in broad terms and an hour-long test you can run with your own document. The ten APIs worth a trial are further down.
Rendering a page versus filling a template
A converter takes HTML and CSS you've already written, or a live URL, and prints it to PDF. Your app owns the layout. That's ideal when the document already exists as a web page, such as an order confirmation or a dashboard export, and it means your front-end team can style it with tools they know. The quality of the result comes down to the rendering engine and how well it handles print CSS: page breaks, repeating table headers, running footers and page numbers. Browsers were built for screens, so a converter that takes print CSS seriously saves you a lot of hacks.
A template service flips that. Someone designs the document once, often in a visual editor, and your app sends only the data as JSON. The layout lives outside your codebase, so a finance or operations colleague can move a logo or change a clause without a deploy. The price you pay is another system to keep in step with your data model, and if someone renames a field, the template quietly prints a blank.
My rule of thumb: if the document is mostly a view of something your app already shows on screen, convert it. If it's a business document that non-developers will want to change, template it.
Hosted, self-run, or both
Most of these are hosted APIs: you send a request, you get a file, and someone else runs the servers. That's the right default for a small team, because PDF rendering is fiddly to operate. Headless browsers eat memory, fonts go missing in containers, and a stuck job can quietly back up a queue.
Two of the ten are different. One is a Docker-based engine you run yourself, and another is an open source generator with a hosted cloud alongside it. Self-running makes sense when documents hold data that mustn't leave your infrastructure, such as health letters, payslips or signed contracts, or when your volume is high enough that per-document billing starts to hurt. It doesn't make sense when nobody on the team wants to own another service at two in the morning.
Where the hosted service runs matters too. At least one option here keeps its cloud in the EU, which is a plus for European data rules and a problem if your contracts require a US region. Ask before you build, not after.
Five mistakes developers make with PDF APIs
Comparing headline prices that count different things. In this category the billing unit varies wildly: documents per month, credits that shrink faster on large files, megabytes of bandwidth plus compute time, or document transactions. A plan that looks cheap for one-page receipts can turn expensive for image-heavy reports. Work out your monthly volume and typical file size first, then price that.
Testing with a one-page sample. Everything renders a one-page invoice well. The failures show up on page seven: a table row split across a break, a header that doesn't repeat, a footer that overlaps the last line. Test with your longest realistic document.
Treating the free tier as production. Free allowances are sized for experiments, and some vendors say so plainly. Build your proof of concept on one, then check what happens at the limit: a hard stop, a per-document charge or an automatic upgrade. Each of those breaks your app in a different way.
Forgetting compliance formats. If your PDFs are invoices for European customers or documents that must be archived, ask about PDF/A, accessible PDF/UA and e-invoice formats such as Factur-X early. A couple of the tools here validate or convert to these; most don't mention them.
Hard-coding one vendor. Wrap the call in your own small service with a single function, such as render(template, data). Swapping providers later then means changing one file, not hunting through the codebase.
What PDF generation costs
Across the ten, entry paid plans mostly sit somewhere between five and fifty dollars or euros a month, the larger published plans run to a few hundred a month, and the biggest vendor quotes high volume through its sales team. Most offer some free allowance, from a handful of documents to a few hundred transactions a month. Self-hosted open source costs nothing to license and everything in server time and attention, so price your own hours honestly before you call it free.
Two things a few of these tools do differently
Some tools, such as PDFMonkey and CraftMyPDF, take the layout out of your code altogether: you design the document once in a visual editor and send only data, which suits teams where non-developers own the template. And a couple go further than producing the file. Gotenberg validates PDFs against archive and accessibility standards, including the Factur-X e-invoice format, and PDF.co can convert PDFs into e-invoices. If your documents are heading for an accounts department, check for those features specifically, because the rest of the list doesn't advertise them.
Ten APIs worth a trial
DocRaptor
HTML to PDF conversion on the Prince engine, with strong support for print CSS such as page breaks and running headers.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
PDFShift
A plain conversion API: send it HTML and CSS or a web address, and a PDF comes back.
Api2Pdf
One serverless REST API that turns HTML, URLs, Markdown and Office files into PDFs, then merges or watermarks them.
PDFMonkey
Template-first: you design the document once in a visual editor, send your data, and get PDFs or images back.
CraftMyPDF
Design-once templates that you can drive from no-code automation tools as well as from a REST API.
APITemplate.io
Reusable templates for PDFs and images, with direct HTML to PDF and URL to PDF calls when a template is too much.
Carbone
Open source document generator that fills templates with JSON and outputs PDF, Word or Excel, self-run or in its EU cloud.
Gotenberg
A Docker-based API you host yourself, converting web pages and office files to PDF and validating them against archive standards.
PDF.co
A toolkit API for working on existing PDFs as much as making them: extracting, editing, converting, merging and splitting.
Adobe PDF Services
The big-vendor choice here, Adobe's API family for creating, converting and running OCR on PDF files.
An hour-long test with your own invoice
- Take one real document your app produces, with its longest realistic data set, and save it as HTML or as sample JSON.
- Put it through two services, one converter and one template service if you're unsure which job you have.
- Print both results and check page breaks, split table rows, fonts, headers and page numbers.
- Run the same call fifty times and see what each dashboard says you've used, so you know the real unit you'll pay for.
- Read what happens at the plan limit, and wrap the one you keep behind one function in your own code.
Which kind to start with
If your app already renders the document as a web page, a converter is the shortest path, and one built on a print-focused engine is where I'd begin when layout matters. If documents are built from records and someone outside engineering owns the design, start with a template service that has a visual editor. If data can't leave your servers, go straight to a self-hosted engine and accept that you're now running infrastructure. And if your real job is working on PDFs that already exist, splitting, merging or pulling data out, a broad toolkit API fits better than any generator.
If your inputs start life as Word files, this walk-through on converting Word to PDF covers the manual route, and for reading text back out of scans, see these benefits of OCR document scanning.
Do you make a PDF generation or document API? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
