Browserbase alternative for PDF generation: what a browser hour actually buys

If you are leaving Browserbase because PDF generation is costing too much, check the arithmetic first, because it probably is not. Browserbase meters browser hours, and a PDF render takes roughly four seconds. On the $20 Developer plan the 100 included hours work out to about 90,000 renders a month before you pay a cent of overage. The real reason teams move document workloads off Browserbase is different, and it is worth being precise about it. Every figure below was read from the vendors' own pricing pages on 9 September 2026.

Browserbase's own example assumes a task 30 times longer than a PDF render

There is a line on the Browserbase pricing page that explains the whole confusion. Under a heading asking which plan fits, it says:

"A browser hour goes further than you think. A typical web scrape runs in under 2 minutes. 100 hours is roughly 3,000 page-level tasks."

That is honest and useful, and it is also the wrong unit for you. Work backwards from it: 100 hours across 3,000 tasks is two minutes a task. That is a sensible assumption for an agent that loads a page, waits for content, clicks through a flow and extracts something.

A PDF render is not that. You post HTML, Chromium lays it out, and you get a file back. Four seconds is a realistic figure for a document with a few images and a web font, and it is the number we have used consistently across our cost work. Four seconds is thirty times shorter than Browserbase's stated example.

So the same 100 browser hours that Browserbase describes as "roughly 3,000 page-level tasks" are, for a document workload, roughly 90,000 renders. An hour holds 900 four second renders. The vendor is not overselling here, it is underselling, because it is describing the workload it was built for rather than yours.

The same job at three vendors, and the 6.6x gap between two of them

Fix the job at 100,000 PDF renders a month, four seconds each. That is 111.1 browser hours. Here is what each option bills, on rates read 9 September 2026.

Option	What it meters	100,000 renders a month	Per render
Self-hosted Chromium on AWS Lambda (x86, 1,600 MB)	GB-seconds, continuous	$10.44	$0.000104
Browserbase Developer ($20, 100 browser hours included)	Browser hours, continuous, then $0.12/hr	$21.33 $20 plus 11.1 hours overage	$0.000213
Browserless Starter ($140, 180,000 units included)	Units, a block of "up to 30 seconds"	$140.00	$0.001400

Two of those three are managed cloud browser platforms sold to the same buyer for the same reasons, and on this job one costs 6.6 times the other. Nothing about the underlying work differs. The gap is entirely the metering unit.

Browserless defines a Unit as "a block of browser time of up to 30 seconds per browser connection", with "an extra Unit for every 30 seconds". A four second render consumes a full 30 second block and uses about an eighth of it. Browserbase bills the hour continuously, so a four second render costs four seconds. That is the whole explanation, and it is the same block versus continuous distinction that decides so many of these comparisons.

The other thing this table shows is that Browserbase sits only about 2x above running Chromium yourself on Lambda. We priced the self-hosted side in detail in our breakdown of what @sparticuz/chromium on AWS Lambda actually costs, and the conclusion there holds here: the compute difference across a year is small enough that it buys ten to twenty engineer-hours, so the invoice is not what should decide this.

The $20 plan beats the "most popular" $99 plan until about 1.8 million renders

Browserbase marks Startup at $99 as MOST POPULAR, and for agent workloads that is probably right. For pure document rendering it is wrong for a very long time.

Developer costs $20 plus $0.12 for every hour past 100, so its cost curve is 8 + 0.12h. Startup costs $99 plus $0.10 past 500, so its curve is 49 + 0.10h once you are over the included allowance. Set them equal and the crossover lands at 2,050 browser hours a month, where both plans cost $254.

At 900 renders an hour, 2,050 hours is 1,845,000 renders a month. Below that, the cheaper plan with overage genuinely wins. This is unusual and worth checking against your own numbers, because the normal shape in this category is the opposite: at ConvertAPI, for instance, overage is a flat $0.05 on every plan against in-plan rates as low as $0.007, so exceeding a large plan costs 7.1 times the in-plan rate and buying the next rung up early is the right move. Browserbase's overage is close enough to its in-plan rate that the rung barely matters. Do not carry an instinct from one vendor to the other.

The caveat: concurrency, not price, is what usually forces the upgrade. Developer allows 25 concurrent browsers and Startup allows 100. At 100,000 renders a month spread evenly you need well under one concurrent browser, but real traffic is not even, and a month-end statement run that fires ten thousand renders in an hour will hit the concurrency ceiling long before it hits the hour ceiling.

Where Browserbase is genuinely the right product

Three cases, and none of them is about cost.

Stateful sessions. If the document you are rendering sits behind a login, or requires clicking through a multi-step interface before the printable view exists, you need a real browser you can drive. Browserbase gives you that with session persistence, replays and 30 day retention on the paid tiers. A rendering API that accepts HTML or a URL cannot log in to somebody else's application for you.

Anti-bot work. Stealth mode, automatic captcha solving and proxy handling are real features with real engineering behind them. If you are rendering pages that actively resist automation, this is worth paying for.

You are already there for agents. If Browserbase is running your agent workloads through Stagehand and PDF rendering is a small side job, the marginal cost of keeping it there is close to zero, and consolidating vendors has its own value. Splitting a workload across two providers to save fifteen dollars a month is not a good trade.

The actual reason document workloads leave, and it is not the invoice

What you are buying from Browserbase is a browser. What you need for a PDF is a document, and the distance between those two things is code you have to write and keep alive.

A browser platform hands you a Chromium instance and a Playwright or Puppeteer connection. Everything after that is yours: calling page.pdf() with the right options, getting page breaks to fall between table rows rather than through them, making headers and footers repeat with working page numbers, setting a real Letter or A4 page size with margins, waiting for web fonts and images and charts to finish before you print, and handling the render that hangs. We have written about most of these individually, and the one that costs the most in production is knowing when the page is actually ready to print, because getting it wrong produces a PDF that looks fine in testing and arrives half-rendered for a customer.

That is a real, ongoing maintenance surface. It also has an operational tail: a rendering endpoint that quietly starts returning blank pages or timing out is the kind of failure nobody notices until a customer complains, which is why it belongs behind proper uptime monitoring for your API endpoints rather than a dashboard somebody checks on Mondays. Hung renders are expensive in their own right on per-invocation platforms, as we worked through in the Playwright on Lambda cost breakdown, where a timeout is billed at its configured ceiling rather than at the render time.

A PDF rendering API collapses all of that into one HTTP call with page size, margins, headers and footers as parameters. You stop maintaining browser code and start maintaining a template. That is the trade, and it is a staffing decision rather than a hosting one.

How to decide, in about ten minutes

Answer these in order and the choice usually makes itself.

1. Does the document require interaction to reach? Login, multi-step flow, captcha. If yes, stay on a browser platform. Browserbase is a good one.
2. Do you already run agents there? If yes, leave the PDFs where they are unless the rendering code is genuinely painful.
3. Are you rendering your own HTML from your own data? If yes, you are maintaining browser plumbing for no reason. A rendering API is the category, and our comparison of HTML to PDF APIs covers who is in it.
4. Is cost the reason you are asking? Recheck it. At four seconds a render, Browserbase is inexpensive for this job, and if the number you are looking at seems high, the likely culprit is session duration rather than volume.

That last point deserves a sentence of its own. Because Browserbase bills elapsed browser time, a session left open while your code does something else bills the whole time it was open. Ten seconds of render inside a session that stays alive for ninety seconds costs ninety seconds. If your Browserbase bill looks wrong for the number of PDFs you produce, look at when you close the session before you look at plans. We keep the full rate card and metering detail on our Browserbase pricing page, and the self-hosted comparison sits on the Puppeteer alternative page.

Frequently asked questions

What is the best Browserbase alternative for generating PDFs?

It depends on why you are leaving. If you need cheaper compute and are willing to maintain the code, self-hosted Chromium on AWS Lambda costs about $10.44 per 100,000 four second renders against Browserbase's $21.33. If you want to stop maintaining browser code altogether, the replacement category is a PDF rendering API, not another browser platform. Browserless is the closest direct equivalent to Browserbase but bills in 30 second blocks, which makes it roughly 6.6 times more expensive on short renders.

How much does Browserbase cost?

Read 9 September 2026, Browserbase publishes four tiers: Free with 3 concurrent browsers and 1 browser hour, Developer at $20 a month with 25 concurrent browsers and 100 browser hours then $0.12 per hour, Startup at $99 with 100 concurrent browsers and 500 hours then $0.10 per hour, and Enterprise on custom pricing with 250 or more concurrent browsers. Search calls run $7 per 1,000 and Fetch calls $1 per 1,000 above the included allowances.

How many PDFs can I generate on the Browserbase free plan?

The Free tier includes one browser hour a month. At four seconds a render that is about 900 PDFs, with a 3 concurrent browser limit and a 15 minute session cap. That is enough to build and test a rendering pipeline properly, but not enough to run one in production. The $20 Developer plan's 100 hours covers roughly 90,000 renders at the same assumption.

Is Browserbase cheaper than Browserless?

For short renders, substantially. On 100,000 four second PDF renders a month, Browserbase Developer costs about $21.33 and Browserless Starter costs $140, a 6.6x gap. The reason is the metering unit: Browserless bills a Unit defined as "a block of browser time of up to 30 seconds", so a four second render pays for a block it barely uses, while Browserbase bills elapsed hours continuously. For long-running sessions of 30 seconds or more the two converge and the gap largely disappears.

Should I self-host Chromium instead of using Browserbase?

Only if you value the saving above the maintenance. The difference on 100,000 renders a month is about $10.89, or roughly $131 a year, which buys between one and two engineer-hours at typical US contract rates. Keeping headless Chromium patched, sized and alive on Lambda costs more than that in most teams. Self-hosting wins on cost at every volume and loses on time at almost all of them.

Why is my Browserbase bill higher than my render count suggests?

Almost always session duration rather than volume. Browserbase bills elapsed browser hours, so a session that stays open while your application does other work bills for the entire time it was open, not just the seconds spent rendering. A ten second render inside a session held open for ninety seconds is billed as ninety seconds. Close sessions immediately after the PDF is returned, and avoid reusing one long-lived session as a queue.