HTML to PDF API cost: what these services actually charge, and when self-hosting is cheaper

Pricing an HTML to PDF API should be simple arithmetic and almost never is. You open four vendor pricing pages, and one bills per document, one bills per half megabyte of output, one bills per thirty seconds of browser time, and one bills a base fee plus bandwidth plus compute. The headline numbers look comparable. The bills are not.

This guide translates the four billing models into one number you can actually compare, points out the multipliers that make a cheap-looking plan expensive, and works through the honest break-even against running headless Chromium yourself. All vendor figures below were read directly from the vendors' own pricing pages in July 2026; prices change, so re-check before you sign anything.

The short version

HTML to PDF APIs bill in four ways: per document, per credit where a credit covers a fixed file size, per unit of browser time, or per resource consumed. Per-document is the only model where your cost is predictable from your own numbers. Credit models multiply your cost by document size, so a 12-page report can silently cost three to five times a one-page invoice. Browser-time models reward fast pages and punish slow ones. For most teams the practical break-even against self-hosting sits somewhere in the low tens of thousands of documents per month, because below that the engineering time to run a browser fleet costs more than the API does.

The four billing models

Model	Billing unit	Who uses it	Your cost scales with
Per document	One render, one unit	APITemplate.io, CraftMyPDF, Sitepdf	Number of documents, nothing else
Per credit by size	One credit per fixed output size	PDFShift, PDFCrowd	Documents multiplied by file size
Per browser time	Blocks of browser seconds	Browserless	How long each page takes to render
Per resource	Base fee plus bandwidth plus compute	Api2Pdf	Several variables at once

Only the first model lets you forecast from a number you already know. The other three make your bill a function of something about your documents that you probably have not measured yet.

The size multiplier, the most common surprise

Credit-based pricing is where most teams get the arithmetic wrong, because the credit-to-document ratio is not one to one. PDFShift, as of July 2026, counts one credit per 5MB of output. PDFCrowd counts one credit per 0.5MB. Those are very different meters, and neither corresponds to "a document".

Work an example. Say you generate 5,000 statements a month, each about 1.2MB because they carry a logo, a chart image and a dozen pages of tables. On a 5MB credit that is still one credit each, so 5,000 credits. On a 0.5MB credit that is three credits each, so 15,000 credits, and you need a plan three tiers up from the one you were pricing. Same workload, triple the bill, and nothing on the pricing page told you because the pricing page does not know how big your PDFs are.

Before you compare any credit-based plan, generate twenty representative documents and measure the actual file sizes. That single measurement is the difference between a forecast and a guess. Watch for what inflates it: embedded fonts add a few hundred kilobytes, uncompressed images add megabytes, and a report that grows with your customers' data will grow its bill in step.

The browser-time model

Browserless bills by units representing blocks of browser time, thirty seconds each as of July 2026, with a free tier of 1,000 units and paid plans starting at $25 for 20,000 units. It is a browser-as-a-service product rather than a PDF endpoint, so you script the render yourself with Puppeteer or Playwright, which buys you a lot of flexibility.

The cost characteristics follow from the unit. A fast page that renders in two seconds still consumes a whole thirty-second block, so short renders are relatively expensive per document. A slow page that waits on charts, or an unlucky one that hangs on a networkidle that never settles, burns multiple blocks. That makes your bill a function of your page performance, which is a real variable and not always one you control: a third-party script that gets slower makes your PDFs cost more.

This model suits teams doing more than PDF generation with the browser, scraping, testing, screenshots, where the flexibility earns its keep. For pure document generation at predictable volume, per-document pricing is easier to plan around.

The resource model

Api2Pdf prices pay-as-you-go: a small base fee, around $1 a month, plus bandwidth at roughly a tenth of a cent per megabyte, plus per-second compute. The floor is genuinely the cheapest in the category, and for low or spiky volume that is a real advantage.

The trade is forecasting. Three variables move independently, so your monthly cost is a small model rather than a multiplication. It also runs older engines including wkhtmltopdf, which was archived in 2023, so if you route to that engine you are on unmaintained rendering, and generated files are dropped after 24 hours. The Api2Pdf comparison covers those trade-offs in full.

What the pricing page does not tell you

Four costs sit outside the per-unit rate and routinely dominate it.

Failed and retried renders. Ask whether a failed render consumes a credit. On some services it does. If 2% of your pages time out and you retry twice, you have quietly added 4% to your bill and nobody notices because the line item is just "credits".

The commitment shape. Most vendors sell monthly buckets that do not roll over. If your volume is seasonal, month-end statement runs are the classic case, you either buy for the peak and waste most of the year, or buy for the average and hit overage rates in the months that matter. Check the overage price specifically, since it is often several times the in-plan rate.

Storage and retention. Some services delete files after a day, some store them, some charge for it. If you need to keep what you generated, and finance and compliance workloads usually do, storage you have to build yourself is a real cost that belongs in the comparison. Some vendors bill archiving as an add-on; on Sitepdf a timestamped archive of what was rendered is part of the render call rather than a separate meter.

Rate limits and concurrency caps. A plan that covers your monthly volume can still fail on the one afternoon you need 3,000 documents in ten minutes. Read the concurrency limit, not just the monthly allowance. Batch behavior is worth testing before you commit, and the bulk HTML to PDF page covers what sustained throughput actually looks like.

The real comparison: API versus self-hosting

The honest competitor to any of these is Puppeteer on your own infrastructure, which has no per-render cost at all. Anyone selling you an API should be straight about that, so here is the arithmetic.

The server bill is the small part. A machine that can hold a modest Chromium pool runs somewhere in the tens of dollars a month, so at high volume the raw compute is genuinely cheaper than any API. What costs money is everything around it.

Cost	Self-hosted Chromium	Hosted API
Per-document cost	Effectively zero	The line item you are comparing
Infrastructure	Servers or containers sized for peak	None
Initial engineering	Days to weeks: pooling, timeouts, crash recovery	An afternoon
Ongoing maintenance	Chromium updates, memory leaks, zombie processes	None
Scaling for spikes	You size and pay for peak capacity	Absorbed by the vendor
On-call exposure	Yours, and browser failures are unpleasant	Theirs

Put a number on the engineering line and the picture resolves. A competent implementation of a production browser pool, with concurrency limits, timeout handling, zombie-process cleanup and a retry path, is a week or two of senior engineering time, plus a recurring tax every time Chromium updates or a memory leak surfaces at month end. At a loaded rate, that first fortnight alone costs more than most teams' first two years of API spend at moderate volume.

So the break-even is not really about document count, it is about whether browser operations is work your team should be doing. Below roughly ten to twenty thousand documents a month, an API is almost always cheaper once engineering time is counted honestly. Well above that, with steady volume and someone who already owns container infrastructure, self-hosting starts to win on pure cost. The Puppeteer alternative page works through the operational side in more detail, and the library versus API comparison covers the case where you skip the browser entirely.

Normalizing the comparison

To compare vendors properly, reduce every plan to cost per thousand documents at your real document size:

1. Generate 20 representative documents and record the median file size in megabytes.
2. For credit models, divide your median size by the vendor's size-per-credit and round up. That is your credits per document.
3. For browser-time models, time a render, round up to the vendor's block size, and convert to units per document.
4. Multiply by your monthly volume, add your expected retry rate, and find the plan tier that covers it including your peak day.
5. Add storage if you need to keep files, and check the overage rate for the months you exceed the plan.

Doing this for four vendors takes about an hour and regularly reorders the list, because the cheapest headline plan is frequently not the cheapest bill. It is the same discipline any recurring vendor spend deserves, and if nobody at your company is currently tracking what each of these services actually bills you month to month, the PDF line is rarely the only one that has drifted.

Where Sitepdf sits

We bill per render, not per credit or per second, so a twelve-page statement and a one-page invoice cost the same and your forecast is your document count. Planned pricing is $29, $99 and $299 a month at launch, and the archive of what was rendered is part of the render rather than a separate meter. We are pre-launch, so treat those as the published plan and not a shipped invoice.

Where we are not the cheapest: if your volume is genuinely tiny and irregular, Api2Pdf's pay-as-you-go floor is lower than any monthly plan we will offer. If you are already running Chromium for scraping or testing, adding PDF to that fleet costs you close to nothing extra. And at very high steady volume with existing container infrastructure, self-hosting wins on cost, which is why the table above is in this article at all. For a side-by-side across the whole category, the best HTML to PDF API roundup compares seven tools including where each one beats us, and you can try the converter at the top of this page on any URL before pricing anything.