HTML to PDF API

What the job really is #

A PDF endpoint that only converts markup is the easy quarter of the problem. In a real workflow the same call has to do all of this:

1. Render the page the way a browser would — modern CSS, web fonts, flexbox and grid, SVG, and the print stylesheet if there is one.
2. Know when the page is finished. A chart drawn by JavaScript, a font still loading, an image that arrives late: convert too early and you ship a blank box to a customer.
3. Paginate. Page size, margins, a header and footer on every page, page numbers, and not breaking a table row in half.
4. Fail in a way you can act on. Which asset 404’d, which selector never appeared, which placeholder had no value — not 500 Internal Server Error.
5. Survive being called from a workflow. Retries that do not double-charge, timeouts that are yours to set, and binary output that the next node can actually attach.
6. Not become a security hole. Rendering user-supplied HTML on your own infrastructure means running somebody else’s markup in a browser you own.

Points 2, 4 and 6 are what people underestimate, and points 2 and 4 are where the products in this table differ most.

The five parts that are hard #

When to self-host instead #

Puppeteer or Playwright plus Chromium in a container is a genuinely reasonable answer, and if any of these is true it is probably the right one:

• The documents contain data that must not leave your network, and a DPA is not enough.
• You already run a browser pool for scraping or screenshots, so the hard part is paid for.
• Volume is high and steady enough that the per-document price of any API stops being noise.
• You need a rendering engine that is not Chrome — Prince or WeasyPrint for real print typography, for instance.

What you take on: Chromium in a container is roughly 400 MB and needs its fonts installed explicitly; a leaked browser process will eat a box overnight; and rendering untrusted HTML wants a sandbox you maintain. That is a week of work and then a permanent, small, recurring one. If the answer to “who owns this at 3am” is nobody, buy it.

What the six charge, on 29 August 2026 #

Entry paid tier and the tier nearest 5,000 documents a month, so the columns are comparable. Every cell is the vendor’s published figure; the per-document column is arithmetic on it.

Api2Pdf does not sell tiers: it is $1 a month plus $0.001 per MB of bandwidth and $0.00019551 per second of compute, and their own calculator assumes two seconds per file. A 1 MB PDF at two seconds is therefore about $0.0014 — genuinely cheap, and genuinely hard to forecast, which is the trade they are offering.

Two figures deserve to be read twice. $9 a month buys 500 documents at PDFShift and 5,000 here, and PDFMint’s free tier is the smallest in the table at 10 documents a month against PDFShift’s and CraftMyPDF’s 50 and Doppio’s 400. If what you want is a generous free tier to run a small real workflow on, Doppio’s 400 a month is the honest recommendation on this page.

The unit of billing is where an estimate goes wrong #

“Credits” is not a unit. It means something different at each vendor, and the differences are not small:

A 60-page catalogue with photographs is one document everywhere in that table except PDFShift, where a 14 MB result is three credits by their own example. If your documents are image-heavy, recompute PDFShift’s column with your real output size before you compare anything.

What sits behind a higher plan #

Price per document is the visible axis. The one that bites later is which capability is gated.

These are read from the feature matrices on the same pricing pages on the same day. They move; check them.

Where PDFMint sits, and the one number nobody else publishes #

PDFMint is an HTTP endpoint, not a document builder. You POST HTML, Markdown, a URL or the name of a stored template, and the PDF bytes come back in the response body. Every feature is on every plan, including the free one: password protection, headers and footers, page numbers, custom page sizes, watermarks, images, merging, hosted links, async and webhooks.

The thing worth clicking is not on this page. /status is generated from the service’s own request log and is public without an account — success rate, refused requests, and median, 95th-percentile and slowest render time over the last 24 hours and 7 days. When this page was written it read median 55 ms, 95th percentile 618 ms, slowest 4,804 ms, over 126 documents in 24 hours and 3,033 in 7 days at a 100% success rate. Those numbers will be different when you read them, which is the point: none of the five other products publishes its own latency at all, so this is the only cell in the comparison you can verify yourself before paying anybody.

curl -X POST https://pdf.mintapis.com/v1/pdf \
  -H "Authorization: Bearer $PDFMINT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html":"<h1>Invoice 2026-0042</h1>","format":"A4"}' \
  --output invoice.pdf

What we cannot claim #

No outside customer has paid for PDFMint yet, so there is no case study and no reference to give you. The free tier is the smallest in the table and is sized to prove the thing works, not to run a workflow on. PDFMint runs as a single service in one region — the status page’s uptime figure resets on every deploy, and it says so — so there is no multi-region story and no SLA. And there is no drag-and-drop template designer: if a non-developer has to lay the document out, CraftMyPDF and PDFMonkey are built for that and this is not.

Try it against your own worst page #

A feature table is not a test. The test is the page your current renderer gets wrong — the one with the web font, the JavaScript chart and the table that breaks across a page. Send it to POST /v1/pdf and look at what comes back, including the warnings array, which tells you when the page rendered but was probably not what you meant.

Get an API key   Read the API reference   See the live numbers

The individual comparisons #