PageCapture
Start free
Use casesGuidesDocsPlaygroundPricingLog in
Headless Chrome cost

What headless Chrome costs before anyone is paged

Container minutes are easy to price and rarely the reason teams stop self-hosting. The bill that ends the experiment is the one paid in attention: crashed browsers, pinned versions, memory ceilings and the page that only breaks in production.

See the numbersStart with 100 free captures
cost of running headless chrome · request and resultPAGECAPTURE / 01
The operational surface you stop owning
curl -G https://api.pagecapture.dev/v1/take \
  -H "X-Access-Key: $PAGECAPTURE_KEY" \
  --data-urlencode "url=https://example.com" \
  -d "format=png" \
  -d "full_page=true" \
  -d "wait_until=load" \
  -o page.png
Capture result
succeeded
https://example.com
Noma
Shop now
NEW COLLECTION

Objects for slower mornings.

Thoughtful essentials, made in small batches from natural materials.

Explore the collection
No. 01 · Hinoki
PLANT-BASEDMADE IN SMALL BATCHESREFILLABLE
Artifact
PNG · 1440×900
Billing
1 credit
Engine
stable

No browser lifecycle to own

Crashes, upgrades, zombie processes and pinned Chromium versions stay outside your deployment. The version that produced an artifact is part of our engine manifest.

Memory ceilings are ours

Parallel contexts on a long page are the classic way a self-hosted pool exceeds memory before the rate limiter reacts. Concurrency here is a documented plan limit.

One egress policy

Every navigation, redirect and subresource passes the same SSRF policy. A self-hosted browser pointed at user-supplied URLs is an internal network scanner unless you build that yourself.

Failures do not bill

Self-hosted compute burns money on a failed render; here it does not produce a credit. That difference grows with how hostile your target pages are.

What this costs here

Priced on successful captures that miss cache

Every number in this table is computed from the published plans — failures and organization-scoped cache hits are removed before the plan is chosen, because they are not billable.

ScenarioBillable successesSmallest included planPublished monthly price
1,000 page renders882Basic$10.00
10,000 page renders8,820Growth$47.00
50,000 page renders44,100Scale$155.00

Assumes 10% cache hits and 2% failures. Change either assumption and the billable count changes with it — that is the point of charging for success.

Running Chromium yourself

The part of the bill that is measurable

At 20,000 requests a month, with 20% cache hits and 2% failures, on 0.25 browser-minutes per attempt.

Browser attempts per month
16,000
Self-hosted compute
$12.00
Storage and egress
$25.00
PageCapture subscription
$47.00
PageCapture overage
$21.00
Break-even

0.3

engineering hours per month. Below this, keeping your own browsers is cheaper. We do not publish an assumed figure for your hours — only the line where the answer flips.

Put in your own numbers
What these vendors publish

Their own numbers, not our summary of them

These figures are quoted from each vendor's own pricing page, with the date we last checked it. They are not converted to our billing unit, because they do not measure the same thing.

Browserless

Browser-as-a-service for automation, scraping and agents — not only artifacts.

What a unit is
A block of browser time of up to 30 seconds per connection
Free tier
1,000 units per month
20,000 units
US$ 25 per month, billed annually
180,000 units
US$ 140 per month, billed annually

Published by the vendor, checked 2026-08-14.

browserless.io

ScreenshotOne

A complete, developer-friendly specialist API for screenshots.

Free tier
100 screenshots per month
Entry plan
US$ 17 / 2,000 screenshots per month
10,000 screenshots
US$ 79 per month
50,000 screenshots
US$ 259 per month

Published by the vendor, checked 2026-08-14.

screenshotone.com

These names are trademarked by their respective owners and mentioned only to describe the comparison people are searching for. No affiliation is claimed.

Questions this raises

Is self-hosting cheaper?

On compute alone, often yes — the table above shows it. It stops being cheaper at the point where your own engineering hours enter the calculation, which is why we publish the break-even instead of assuming your rate.

When should I keep running my own browsers?

When the pages are yours, volume is low, the browser is already reliable in your deployment, or the workflow needs arbitrary interaction that is not part of a capture contract. Those are real answers, not a sales objection.

What is not in the measurable column?

Incident time, upgrade work, font and codec drift across environments, and the debugging of pages that only fail in production. We do not price those for you because we cannot measure your team from here.

Does the comparison assume we would rebuild everything?

No. It assumes you already run Chromium successfully. The question is what the next year of keeping it running is worth, not whether you can build it.

Related

Puppeteer build vs API
Keep Puppeteer when browser control is core. Use an API when the artifact is.
Playwright operations
Move screenshot jobs out of your Playwright serverless function
Browserless alternative
A Browserless alternative for teams that want the file, not the browser

Run the page that breaks your current provider.

Open the playground