PDFShift alternative

The full rate card #

In the 29 August snapshot, $9 bought 500 credits against 5,000 PDFMint documents, and $99 bought 25,000 credits against 250,000 documents. PDFShift’s current FAQ now lists its $24 Boost plan for 2,500 credits; check its live calculator for the rate that matches your volume. The archived $799 / 500,000-credit figure is dated, so it is not used as a current comparison here.

What a credit is, and why this is the part to check first #

PDFShift states the rule twice on its own pricing page, in these words:

That is a defensible way to price — a big render costs them more — but it means the per-credit column above is not the per-document price unless your output is small. Take a catalogue or a photo-heavy report at 14 MB: on Starter it costs three credits, so 500 credits is 166 documents, and the real price is $0.054 a document, thirty times PDFMint’s $0.0018. Take a 300 kB invoice and the rule never fires and the honest comparison is the $0.018 in the table.

So the question is not which product is cheaper in the abstract. It is: how many megabytes does your average document weigh? Generate ten typical ones and look. At PDFMint the answer does not change the bill — one credit is one document, at any page count and any size.

Side by side #

What happens when the render fails #

This is the difference that shows up at 3am rather than on an invoice. A PDF render fails for a small number of boring reasons: an asset 404’d, a font never loaded, a selector you waited for never appeared, a placeholder had no value. PDFMint answers with the reason and a request_id:

{
  "error": {
    "code": "unresolved_placeholders",
    "message": "The template uses 1 placeholder that \"data\" does not provide: amount.",
    "hint": "Pass every placeholder in \"data\", or set \"strict\": false.",
    "request_id": "529616e4ed2f7cf1"
  }
}

There is a second layer under that. A page can render successfully and still be wrong — an empty div, a chart that never drew. Those come back as a warnings array alongside a perfectly valid PDF, so a workflow can branch on them instead of mailing a blank page to a customer. The full error and warning list is in the API reference.

The free tiers are not comparable, and ours is the smaller one #

PDFShift gives 50 conversions a month; PDFMint gives 10. That is a real advantage for PDFShift and it is worth saying without spin: if you want to evaluate over several weeks without paying, they give you five times the room. PDFShift’s free tier does cap output at 15 MB and the timeout at 30 seconds, where the PDFMint free tier has the same published request and render limits as its paid plans: a 12 MB request body, 10 MB of rendered HTML and up to 120 seconds per render. But 50 is 50. Ours is sized to prove the thing works, not to run anything on.

If the caller is a workflow tool rather than your code #

PDFShift is an API you call from your own code. If the caller is n8n, Make or Zapier, the question becomes whether there is a node that hands the binary to the next step correctly, which is the part that is fiddly to do by hand with an HTTP node.

PDFMint publishes n8n-nodes-pdfmint — we build and run the service and we publish the node. It attaches the PDF as binary data and puts pages, durationMs, creditsRemaining and any warnings on the item’s JSON next to it, so a downstream IF node can act on them. Details on the n8n page.

The same call, here #

curl -X POST https://api.pdfshift.io/v3/convert/pdf \
  -u "api:$PDFSHIFT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"source": "<h1>Invoice</h1>"}' \
  --output invoice.pdf

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

Both return the bytes in the response body, so a migration is the URL, the auth header and the name of one field. If you need the PDF as base64 or as a hosted link instead, set "output": "base64" or "output": "url".

When to stay on PDFShift #

• Your documents are small and your volume is under about 400 a month. At that size the difference is a few dollars and switching is not worth an afternoon.
• You want the free tier to carry a real evaluation. 50 a month against 10.
• You need a vendor with years of public track record. They have tens of thousands of developers and public reviews on three sites. We have none of that, and no amount of argument changes it.
• You are already integrated and it works. A renderer that has never surprised you is worth more than a price list.

What we cannot claim #

PDFMint has two paying customers, but there is no case study or public reference yet. We used to quote npm’s weekly download count here as if it meant adoption. On 30 August 2026 we checked, and it does not: the downloads are spread almost evenly across every published version, including week-old ones nobody would install, which is what mirrors and scanners look like rather than people. We publish no adoption number now, because we do not have one worth publishing. PDFMint runs as a single service in one region with no SLA, and its status page’s uptime figure resets on every deploy, which it says on the page. Everything else here can be checked with one curl and the two pricing pages, before you spend anything.

Try it against your own worst document #

Take the page your current renderer gets wrong — the web font, the JavaScript chart, the table that breaks across a page — and send it to both. Then weigh the output, because that is what decides which of these two rate cards applies to you.

Get an API key   API reference   Live latency and success rate

Other comparisons #