PDF API Pricing: What 12 HTML to PDF Vendors Actually Charge

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.

A price comparison is only worth reading if somebody re-reads it. Every rate card in the table above was checked again on 21 August 2026, three weeks after the first pass. Here is the honest result, including the boring parts.

Nine of twelve vendors did not move a single number. DocRaptor still steps 125, 325, 1,250, 5,000, 15,000 and 40,000 documents at $15, $29, $75, $149, $399 and $1,000. PDFShift still runs $9 to $999 across ten tiers, still at one credit per 5MB of generated data. Browserless still lists 1,000 free units, then $25, $140 and $350 a month for 20,000, 180,000 and 500,000 units, still billed annually, with published concurrency of 2 max concurrent browsers on Free, 10 plus 5 burst on Prototyping, 40 plus 10 on Starter and 100 plus 20 on Scale. CraftMyPDF still runs $29, $49, $99, $299 and $499. APITemplate.io still runs $24, $89 and $179 monthly. Api2Pdf still charges $1 a month plus $0.001 per MB and $0.00019551 per second. PDFCrowd still refuses to show a price without completing its usage selector. Adobe still publishes 500 free document transactions and no paid rate card at all.

Three vendors published more detail than they did three weeks ago, and in every case it is detail that helps a buyer rather than a price rise.

• Urlbox now prints an overage rate against each tier: $9.50 per 1,000 on Lo-Fi, $9.80 on Hi-Fi and $6.60 on Ultra, with Business structured as a $495 base plus $3 per 1,000 renders. That matters more than it looks. Overage rates are usually the least visible number on a pricing page and frequently several times the in-plan rate. Urlbox overage is close to its in-plan rate, which makes it one of the few services here where running slightly over your plan is not punished.
• PDFMonkey now publishes pay as you go pricing on its top two tiers, for extra documents once pay as you go is enabled, at EUR0.006 a document on Pro+ and EUR0.005 on Premium, alongside the EUR5 Boost Packs and a 10 percent discount for annual billing. Retention is published per tier too: one day on Free and Starter, one week on Pro, unlimited on Pro+ and Premium. For our 10,000 document benchmark the Boost Pack route still wins: EUR60 plus five packs is EUR85, against EUR60 plus 5,000 documents at EUR0.006 which is EUR90.
• PDF.co now shows the credit allowance on its Business tiers, which were previously priced without a published quantity: 80,500 credits at $44.99, 159,850 at $89.99 and 483,000 at $270. The per-operation credit cost is still unpublished, so the plans remain uncomparable on a per-document basis, but at least the ladder is visible now.

The useful conclusion for anyone budgeting: hosted PDF API pricing is stable on a one month horizon and unstable on a one year horizon. Nothing in this category repriced in three weeks. Over the same period three vendors added transparency and none removed it, which is the opposite of the drift you see in the self hosted SDK market, where Syncfusion withdrew its published per developer price entirely and now quotes every tier. Re-check before you sign, not before you shortlist.

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.

One cost this table cannot show you sits in the third option: buying a commercial rendering library and running it yourself. Those are priced per developer or per legal entity rather than per document, so they never appear on a cost per 1,000 basis, and several of the popular ones are dual licensed in a way that obliges you to publish your own source if you do not pay. In .NET that gap runs from free under MIT to 4,799 USD perpetual, with iText commercial pricing available only by quote. We put the verified figures in one place: what iText, QuestPDF, IronPDF and PDFsharp actually charge, and the C# PDF library page compares them on capability as well as cost. If you are weighing a perpetual license against a subscription, those are the numbers that belong on the other side of the equation.

If the answer you land on is a managed browser rather than a render API, that market prices differently again, and a one minute billing minimum can separate two vendors quoting the same hourly rate by more than twenty times. Eight of them are normalized to one workload on our Browserbase pricing page.

The $29, $99 and $299 tiers on our pricing page are published so you can sanity check the economics before spending an afternoon on an integration.

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.