PDF API Pricing: HTML to PDF API Cost and PDF Generator Rates Compared

Open four PDF API pricing pages and the headline numbers look comparable. They are not, because the vendors are not selling the same unit.

Per document is the honest one. One render, one unit, and your monthly bill is your document count times a rate you can read off the page. DocRaptor, CraftMyPDF, APITemplate.io, PDFMonkey and Sitepdf all work this way. You can forecast it from a number you already know, which is why it is the model to prefer when everything else is equal.

Per credit tied to output size is where most teams get the arithmetic wrong, because the credit is not a document. PDFShift counts one credit per 5MB of generated data. PDFCrowd counts one credit per 0.5MB. Those are ten times apart, and neither corresponds to "a document". A 1.2MB statement is one credit on PDFShift and three on PDFCrowd. Same file, triple the meter reading.

Per unit of browser time is Browserless. A unit is up to 30 seconds of browser connection, so a page that renders in 2 seconds still burns a whole unit, and a page that hangs on a network call that never settles burns several. Your bill becomes a function of your front end performance, which is a variable you only partly control: a third party script that gets slower makes your PDFs more expensive.

Per resource is Api2Pdf: a $1 base fee, plus bandwidth at $0.001 per MB, plus compute at $0.00019551 per second. It has the cheapest floor in the category by a wide margin, and it is the hardest to forecast, because three variables move independently and none of them is "documents".

The practical consequence: before you compare any credit based or resource based plan, generate twenty representative documents and measure the actual file sizes and render times. That one measurement is the difference between a forecast and a guess.

The last two columns of the table are ours, not the vendors'. Here is exactly how they were built, so you can redo the sum with your own numbers.

The benchmark workload is 10,000 documents a month, about 1MB of output each, about 3 seconds of render time each. That is a fairly typical invoice, statement or report run: a dozen pages, a logo, a chart, embedded fonts. Then for each vendor we applied their own rules and picked the cheapest plan that actually covers the work.

For per document services that is simply the first tier at or above 10,000. For PDFShift, 1MB output means one credit per document, so 10,000 credits, which fits the $99 tier at 25,000. For PDFCrowd the same document would cost two credits at 0.5MB per credit, so 20,000 credits, but there is no published price to attach to that. For Browserless, a 3 second render fits inside one 30 second unit, so 10,000 units, comfortably inside Prototyping at 20,000 units for $25. For Api2Pdf the arithmetic is $1 base, plus 10,000MB of bandwidth at $0.001 which is $10, plus 30,000 seconds of compute at $0.00019551 which is $5.87, totalling $16.87.

Three caveats worth stating plainly. The Browserless figure is billed annually, so the real commitment is $300 up front rather than $25 a month. The PDFMonkey figure combines the EUR60 Pro+ tier with five EUR5 Boost Packs, which is cheaper than jumping to the EUR300 Premium tier, but it does mean managing top-ups. And the Urlbox per-document figure differs depending on whether you measure against the plan cap of 15,000 renders or against the 10,000 you actually generate, which is true of every tiered plan and is precisely why we normalize on documents generated rather than documents allowed.

Rerun the sum with your own file size and you will see the ranking move. Double the output size to 2MB and PDFShift stays put while PDFCrowd doubles again. Push render time past 30 seconds on slow pages and Browserless doubles. Halve the volume to 5,000 and DocRaptor drops from $399 to $149 and stops being an outlier. There is no universally cheapest PDF API, only the cheapest one for a document shape you have measured.

DocRaptor charging $399 for 10,000 documents is not a story about DocRaptor being greedy. It is a story about tier spacing. Its plans step 5,000 then 15,000, so a workload at 10,000 pays for 15,000. At 5,000 documents DocRaptor costs $149 and sits mid-pack; at 15,000 it costs $399 and is roughly $26.60 per 1,000, which is expensive but no longer absurd. The penalty is entirely about where your volume lands between two rungs.

Every tiered vendor has this shape somewhere. PDFMonkey jumps from 5,000 documents at EUR60 to 60,000 at EUR300, a twelve times capacity increase, which is why the Boost Pack route matters so much for anyone in between. APITemplate.io steps 3,000 then 12,000. CraftMyPDF steps 3,000 then 12,000 then 40,000.

So before you compare headline prices, find your volume on each vendor's ladder and check how far it sits from the rung below. Landing just above a rung is the single most common way teams overpay by three times without ever seeing a surprising invoice. If your volume is seasonal, and month-end statement runs are the classic case, that problem compounds: you either buy for the peak and waste eleven months, or buy for the average and pay overage in the months that matter. Ask for the overage rate specifically, because it is frequently several times the in-plan rate.

Failed and retried renders. Ask whether a failed render consumes a credit. On several services it does. If 2 percent of your pages time out and your client retries twice, you have quietly added 4 percent to the bill and the line item still just says "credits". This is worth an explicit question in writing before you sign.

Concurrency, not just volume. A plan that covers your monthly total can still fail on the one afternoon you need 3,000 documents in ten minutes. Browserless publishes concurrency openly, 2 browsers on free, 15 on Prototyping, 40 on Starter, 100 on Scale, which makes it easy to check. Most others bury it. Read the concurrent request limit before the monthly allowance, because it is the number that decides whether your month-end run finishes. Our bulk HTML to PDF page covers what sustained throughput actually looks like in practice.

Storage and retention. Some services delete generated files after 24 hours, some store them, some charge separately for it. If you need to keep what you generated, and finance, legal and compliance workloads almost always do, then storage you have to build yourself belongs in the comparison as a line item. This is the one place Sitepdf's pricing differs structurally rather than numerically: a timestamped archive of what was rendered is part of the render call, not a second meter.

Egress and file transfer. Api2Pdf bills bandwidth explicitly, which at least makes it visible. Most vendors fold it into the unit price, which is fine until you generate unusually large documents, at which point a "per document" plan quietly develops a size sensitivity nobody mentioned.

Sometimes, and later than most engineers assume. The honest comparison is not API price against server price, because the server is the cheap part.

A Puppeteer or Playwright container that renders PDFs will run happily on a small instance. Call that a modest monthly compute bill. Against $99 a month for 10,000 documents, self-hosting looks like an easy win on that line alone, and if the arithmetic stopped there nobody would buy a PDF API.

It does not stop there. Chromium in production needs memory limits and process recycling because a browser that renders thousands of pages a day will leak and eventually wedge. It needs a font stack installed in the image or your PDFs render in fallback fonts that look nothing like your staging environment. It needs a concurrency limiter, because unbounded parallel browsers is the standard way to take out the host. It needs timeout and retry handling for pages that never reach a settled state. It needs someone to track Chromium security releases. And every one of those is engineering time on a system that generates no revenue by itself.

The rough break-even for most teams sits somewhere in the low tens of thousands of documents a month, because below that the engineering hours cost more than the API does, and above that the per-document rates start to dominate. Two things move that line. If you already run a browser fleet for scraping or testing, the marginal cost of adding PDF rendering is genuinely small and self-hosting wins much earlier. If your documents are regulated and someone will eventually ask you to produce what was generated on a given date, the storage and audit layer you would have to build pushes the line the other way. Gotenberg is the sensible starting point if you go this route, and the Gotenberg comparison covers what it does and does not handle. The library versus API guide works through the same decision from the code side.

Sitepdf is pre-launch. The $29, $99 and $299 tiers on our pricing page are the numbers we are engineering the unit costs around, published early so you can sanity check the economics before spending an afternoon on an integration, and locked for 12 months for early access members. We are putting them in a comparison table alongside vendors who are shipping today, and you should weigh them accordingly: a planned price carries less evidence than a live one.

On raw per-document rate we are not the cheapest thing here and we are not going to claim otherwise. Api2Pdf's pay as you go floor is genuinely lower, and if your volume is small or spiky it is hard to beat. Browserless at $25 for 20,000 units is excellent value if you are comfortable writing the Puppeteer script yourself and can live with annual billing.

The structural difference is what the price includes. On every service in this table, keeping a copy of what you generated is your problem: you build the storage, the retention policy, the retrieval endpoint and the index that maps a document back to the moment it was produced. On Sitepdf that record comes back from the same call that produced the PDF, addressed by id, with the source URL and capture time attached. If your documents are invoices, statements, disclosures or anything a regulator or a customer might ask about in eighteen months, that is a second system you do not build, do not run and do not pay for separately. If your documents are throwaway, it is a feature you will never use, and one of the cheaper options above is the right answer.

For a feature-by-feature view rather than a price-by-price one, the best HTML to PDF API comparison covers rendering engines and output fidelity, and document generation API covers the template merge side of the market, which prices very differently again.