Browserbase and Browserless Pricing: 8 Headless Browser API Rate Cards Compared

Put the four session based vendors side by side and the advertised rates look interchangeable. Hyperbrowser charges $0.10 a browser hour. Steel charges $0.10 on Launch and $0.08 on Scale. Browserbase charges $0.12 on Developer and $0.10 on Startup. Browserless does not quote an hourly rate at all, but its units work out at $0.24 an hour on the cheapest paid tier and $0.18 on Scale. On that evidence you would shortlist on features and move on.

Now give all four the same work: a page that takes about three seconds to load and render. Here is what each one actually charges for those three seconds.

Hyperbrowser bills per second. Its pricing page states the rate plainly, "100 credits/hr" for browser sessions, "Per active browser instance. Billed per second." Three seconds of work bills three seconds of time. At one credit equal to $0.001, 1,000 of those renders costs roughly eight cents.

Browserbase bills by the minute with a floor. The pricing page does not say this; the documentation does: "Browser time is billed by the minute and proxy bandwidth by the MB, rounded, with a one-minute and one-MB minimum per session." A three second session is therefore a one minute session as far as the invoice is concerned. You pay for sixty seconds and use three. Across 1,000 renders that is 16.7 browser hours instead of 50 minutes, or about $2.00 on Developer.

Steel also bills by the minute, and says so. Its documentation states that "Browser hours are billed by the minute, rounded up." Same arithmetic, slightly cheaper rate: about $1.67 on Launch and $1.33 on Scale.

Browserless bills a 30 second block. Its unit pricing explainer defines the unit twice, and both definitions matter. First, "Each webpage you scrape, each PDF you generate, or each test browser you launch is a Session, and will be one Unit." Second, "If a Session is long-lived, every 30 seconds of that Session is a Unit; so a 75-second Session would be 3 Units." A three second render is one unit, so you pay for a 30 second block and use a tenth of it.

The spread that produces is the finding. Four vendors whose advertised hourly rates sit within four cents of each other bill between $0.08 and $2.00 for the identical 1,000 renders, a difference of about twenty five times, and the variable is entirely the size of the smallest slice each one will sell. Only one of the four puts that slice on the pricing page. If your workload is made of short, independent jobs, the granularity is the price, and the hourly rate is close to decoration.

None of the above is an argument that Hyperbrowser is simply the cheapest. It is an argument that the shape of your workload picks the winner, and short renders are only one shape.

Rounding punishes you exactly once per session. Stretch the session out and the penalty amortizes to nothing. An AI agent that opens a browser, logs in, navigates four pages and completes a checkout might hold a session for ten minutes. On a ten minute session, a one minute minimum is a rounding error and the advertised hourly rate is the whole story. Run the same four vendors on continuous session time and the table looks different:

• Steel Scale, $0.08 a browser hour. The cheapest published session time here, though it sits behind a $250 a month plan.
• Steel Launch, Hyperbrowser and Browserbase Startup, $0.10. A three way tie at the rate most of this market has settled on.
• Browserbase Developer, $0.12. The entry tier premium.
• Browserless, $0.18 to $0.24. Now the most expensive of the four, because 120 thirty second units make an hour and the unit price never drops below $0.0015.

So Browserless is roughly twice the price of Browserbase for a long agent session, and roughly the same price as Browserbase for a short one. Hyperbrowser is level with the field on long sessions and about twenty times cheaper on short ones. Steel is either the cheapest or mid table depending on which plan you can justify. There is no ordering of these vendors that survives a change in session length, which is why a comparison article that prints one price per vendor cannot help you.

The practical step is to measure your median session duration before you read anyone else rate card, including this one. If it is under thirty seconds, shortlist on billing granularity. If it is over five minutes, shortlist on the hourly rate and ignore granularity entirely. If your workload is a mix, and most real ones are, price the two halves separately and expect to want different vendors for each.

The second half of the table looks damning for the screenshot vendors. ApiFlash Lite is $7.00 per 1,000 screenshots, ScreenshotOne Basic is $8.50, Urlbox Lo-Fi is $9.50, against roughly eight cents of raw browser time on Hyperbrowser. That is a hundredfold difference, and it is real, but reading it as a hundredfold markup is a mistake that will cost you a quarter of engineering time.

A browser API sells you a browser. What arrives is a WebSocket endpoint and a Chrome instance, and everything between that and a usable PNG is yours to build: waiting for the right load event, blocking ads, dismissing cookie banners, loading and subsetting fonts, handling lazy loaded images, choosing a viewport, capturing full page rather than viewport, encoding to WebP or JPEG, retrying the eight percent of pages that fail the first time, storing the output somewhere, and expiring it. A screenshot API sells you the finished artifact with all of that already decided. Urlbox, ScreenshotOne and ApiFlash all ship ad blocking, cookie banner suppression and full page capture as request parameters.

Look at where the two lines converge and the picture gets clearer. At volume the screenshot APIs come down sharply: ApiFlash is $1.80 per 1,000 on its $180 Large plan, and Urlbox marginal pricing on Business is "$3 per 1,000 renders". Meanwhile Browserbase and Browserless, both billing in blocks, sit at $1.50 to $2.00 per 1,000 short renders. At 100,000 screenshots a month, a dedicated screenshot API is priced at or below what you would pay for the block rounded browser time alone, before you have written a line of the pipeline.

The honest rule is about where the value sits. Take raw browser time when the browser work is genuinely custom, when sessions are long, or when you are running an agent rather than producing a document. Take a render API when the output is a standard artifact, because at that point you are not paying a markup on Chrome, you are declining to maintain a rendering pipeline. Our own screenshot API and PDF API pricing comparison both sit on that second side of the line, and the twelve vendor table on the pricing page is the better read if PDFs rather than images are the output you need.

Browserbase is a good product and the volume of searches for an alternative mostly reflects how visible it is rather than anything wrong with it. The useful question is not which vendor is better, it is which of these four billing models matches your workload. Read on 2 September 2026:

One workload deserves separating out before you read the four, because it inverts the usual conclusion. If the job is PDF generation rather than scraping or agent work, sessions last seconds rather than minutes, and the continuous hour metering at Browserbase makes it unusually cheap: the 100 hours on the $20 plan cover roughly 90,000 four second renders. We worked the arithmetic through, including why the $99 plan does not pay for itself until about 1.8 million renders a month, in choosing a Browserbase alternative for PDF generation.

If your jobs are short and independent, look at Hyperbrowser first. Per second billing is worth roughly twenty times the difference in advertised rate at three second sessions, and the Startup plan is $30 a month for 30,000 credits with 25 concurrent browsers. The trade is a smaller company and a shorter track record than Browserbase, and 7 day data retention on the free tier rising to 30 days on paid.

If you need concurrency cheaply, look at Steel. Launch is $0 a month plus usage with $30 of one time credits and, per its documentation, 10 concurrent sessions. Scale at $250 a month brings 100 concurrent and drops browser hours to $0.08 and proxy to $6 per GB. Steel is also open source, which matters if you may eventually want to self host.

If you want one bill for browsers, proxies and captchas, Browserless is the tidiest. The unit abstraction that makes short jobs expensive is the same abstraction that makes the invoice legible: 6 units per MB of residential proxy, 2 per MB of datacenter proxy, 10 per captcha solve, all in one currency. It also has the only genuinely self hostable commercial offering of the four, under an enterprise license.

If your real problem is being blocked, Bright Data is a different category. At $8 per GB pay as you go, its Scraping Browser is priced on bandwidth rather than time and bundles unblocking and residential proxy infrastructure that none of the other four match. Compared on raw browser time it looks expensive. Compared on pages successfully retrieved from a site that fights back, it frequently is not. That is also why it is the wrong tool for rendering your own application pages, where nothing is blocking you and you would be paying for infrastructure you have no use for.

For the narrower case where the job is turning a page into a document rather than driving a browser, our Browserless alternative and Puppeteer alternative pages cover what changes when you stop managing Chrome yourself.

The other side of that decision is what these vendors are replacing. Running the same browsers yourself on AWS Lambda costs about $10.44 of compute per 100,000 four second renders against $140 on the Starter unit plan here, roughly 13 times less on the invoice and a great deal more in maintenance hours. We put the two models side by side, including the point near 30 seconds where block pricing and per second billing cross over, in our breakdown of Sparticuz Chromium AWS Lambda cost.

Five things decide the bill, and only the first is on the pricing page.

1. Your median session duration. Instrument it before you shop. Everything above turns on this number and most teams guess it wrong, usually low, because they time the render and forget browser startup, navigation and teardown.

2. The minimum billing increment. Per second, per minute, per 30 second unit or per GB. Ask directly if it is not published. On short jobs this is worth more than the headline rate by an order of magnitude.

3. What a failure costs. A page that times out still consumed browser time, and every vendor here bills it. If your target sites fail ten percent of the time, your effective price is ten percent higher than any table shows, including this one. Browserless is explicit that reconnects start a new billable session.

4. Proxy bandwidth, priced separately everywhere. $12 per GB on Browserbase Developer, $10 on Browserbase Startup and Steel Launch, $6 on Steel Scale, 10,000 credits per GB on Hyperbrowser, and 6 units per MB on Browserless residential. On a scraping workload this line routinely exceeds the browser time line.

5. Concurrency, which is the real capacity limit. 25 concurrent browsers on Browserbase Developer, 10 on Browserless Prototyping plus 5 additional, 10 on Steel Launch, 25 on Hyperbrowser Startup. If you need to clear a queue of 50,000 renders in an hour, concurrency and not price per render is what you are buying, and the cheapest per render vendor may simply be unable to do the job at the tier you costed.

Sitepdf is not a headless browser API and it would be dishonest to put it in the table above as though it were. We do not sell you a browser, a WebSocket endpoint or session time, and if what you need is an agent driving a checkout flow or a scraper working through a protected site, every vendor on this page is a better answer than we are.

What we do is the narrow job on the other side of the line: you send a URL or raw HTML, we render it in managed Chromium and return a PDF, and we keep a timestamped archive of exactly what was rendered in the same call. That last part is the reason we exist rather than a feature bolted onto a render API. If you generate an invoice, a policy document or a compliance report, the interesting question six months later is not whether you can regenerate it, it is what it actually said on the day it went out. A render API answers the first question. An archive answers the second.

So the honest routing is straightforward. Driving a browser, take Browserbase, Steel, Hyperbrowser or Browserless. Capturing images of pages at volume, take ApiFlash, ScreenshotOne or Urlbox. Getting past a site that blocks you, take Bright Data. Turning pages your own application already renders into PDFs you may need to prove the contents of later, that is ours, and the best HTML to PDF API comparison is where to check that claim against the alternatives.