Puppeteer Screenshot Testing Costs: Browserless vs Running Chrome Yourself

Direct answer: Browserless charges for browser time in units, while running Chrome yourself trades those usage charges for infrastructure and the work of installing, securing, updating, sizing, and operating browsers. There is no source-backed universal break-even volume. To compare them, apply Browserless’s billing rules to your measured browser sessions, then benchmark the same workload on the self-hosted environment and include hosting, network, and engineering time.

Browserless’s published pricing and sizing information are vendor figures, not an independent cost study. Prices and terms can change; the figures below reflect the research checked on October 3, 2026. Recheck the Browserless pricing page before making a purchasing decision.

What counts as cost in each setup?

A screenshot test’s cost is more than the time spent writing the screenshot file. Measure the entire period a browser connection remains open: launch or connection setup, navigation, readiness waits, rendering, capture, and any idle time before closing.

Cost area	Browserless	Running Chrome yourself
Browser capacity	Plan allowance, unit overages, and plan concurrency limits	Compute and memory sized for typical and peak concurrent sessions
Session duration	Browser time is charged in rounded 30-second units per connection	Longer sessions occupy your capacity longer and can reduce throughput
Setup and maintenance	Managed browser infrastructure; plan and service constraints still apply	Browser binaries, dependencies, container or host setup, security, updates, monitoring, and incident response
Scaling and failure handling	Compare your workload with the selected plan’s concurrency and limits	Build and operate capacity planning, queues, retries, and recovery appropriate to the workload
Other charges	Proxy traffic and CAPTCHA solving can consume units when used	Provider-specific compute, storage, network, and any orchestration costs

A monthly cloud-server price alone is not a complete self-hosting comparison: the required provider, region, workload, utilization, network profile, and labor estimate are not specified here. Nor is a Browserless subscription price alone the cost of a workload that exceeds its included units or concurrency.

How Browserless screenshot billing works

Browserless bills browser session time in 30-second increments. Any partial increment rounds up: a connection open for 31 seconds consumes two units. A session sitting idle still consumes browser-time units, so close it when the screenshot is finished. Reconnecting counts as a new browser connection and incurs a fresh unit charge. Proxy traffic and successful CAPTCHA solving also consume units if those features are used.

For a first-pass estimate, if each job opens one connection and there are no reconnects or other unit-consuming features:

units_per_job = ceil(connection_seconds / 30)
monthly_browser_units = jobs_per_month * units_per_job

For variable session lengths, calculate each session separately instead of rounding the monthly average:

monthly_browser_units = sum(ceil(session_seconds[i] / 30) for each session i)

For example, one 31-second session is two units, while two separate 16-second sessions are two units each, or four total. Averages can hide this rounding effect. This estimate must also add units for reconnects, proxy traffic, or CAPTCHA solving when applicable.

Published Browserless plan figures

The research checked on October 3, 2026 found these self-serve plan figures. Browserless showed the Prototyping price as $25 per month when billed annually, with 20,000 monthly units, up to 10 concurrent browsers, and $0.0020 per overage unit. Its Free tier showed $0 per month, 1,000 units, and two concurrent browsers. Confirm the billing selection and current terms on the pricing page.

Published plan	Price shown in research	Monthly units	Concurrent browsers	Relevant note
Free	$0/month	1,000	2	Plan limits apply; check current terms
Prototyping	$25/month when billed annually	20,000	Up to 10	$0.0020 per overage unit

These are not a complete current plan catalog. The plan page may offer other tiers, billing selections, or terms. Do not extrapolate an overage price to a different plan: use that plan’s published allowance and rate. Concurrency is a separate constraint from units; a workload can fit its monthly units and still exceed the simultaneous-browser limit.

Browserless documents a default connection timeout of 30 seconds in its unit-consumption guidance, and advises setting a timeout to prevent runaway sessions. The appropriate timeout depends on your page and test; too short can turn slow but valid pages into failures. See Browserless unit consumption.

Estimate Browserless cost from your workload

Count jobs. Use monthly screenshot test executions, including scheduled runs and retries that open a new connection.
Measure open-session duration. Record elapsed connection time through navigation, waits, screenshot capture, and close—not just page-load time.
Round each session up. Divide each session duration by 30 seconds and round upward. Sum these units across the month.
Add other unit usage. Include reconnects and any proxy bandwidth or CAPTCHA solving used by the workload.
Check plan capacity. Compare both monthly units and peak concurrent browsers with the plan. Include overages only using the applicable plan’s terms.
Account for failures and retries. Track how often a test reconnects or retries, since that can change both the browser time and connection count.

Keep the duration distribution, peak concurrency, and retry rate alongside the monthly total. A single “screenshots per month” figure cannot describe a workload where some pages take much longer or many jobs run at once.

Run Chrome yourself: a reproducible starting point

For a self-hosted baseline, run a representative Puppeteer capture on the same host or container you intend to operate. The example below uses Node.js, Puppeteer, and Chrome for Testing installed by Puppeteer. Save it as screenshot.mjs, install Puppeteer with npm install puppeteer, then run node screenshot.mjs https://example.com shot.png. The script measures elapsed time from browser launch through capture and close; run it repeatedly at your intended concurrency and collect host/container CPU and memory separately.

import puppeteer from 'puppeteer';

const target = process.argv[2] ?? 'https://example.com';
const output = process.argv[3] ?? 'shot.png';
const started = performance.now();
let browser;

try {
  browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage({
    viewport: { width: 1365, height: 900 },
    deviceScaleFactor: 1,
  });
  page.setDefaultNavigationTimeout(45_000);
  await page.goto(target, { waitUntil: 'networkidle2', timeout: 45_000 });
  await page.screenshot({ path: output, fullPage: true });
  console.log(JSON.stringify({
    target,
    output,
    elapsedSeconds: (performance.now() - started) / 1000,
  }));
} finally {
  if (browser) await browser.close();
}

networkidle2 is only one possible readiness condition. Analytics, long polling, ads, and continuously active pages can prevent network idleness; some pages also appear ready before all relevant content is rendered. Choose a condition that matches the test’s goal, such as waiting for a known selector, then set an explicit timeout and capture failures. For full-page screenshots, lazy-loaded content may require scrolling or page-specific preparation before capture.

This is a measurement starting point, not a capacity guarantee. Page complexity, viewport, fonts, images, browser version, reuse strategy, and simultaneous work all change resource usage. A single successful run cannot establish sustainable concurrency.

Measure self-hosted capacity and operating cost

Browserless publishes these indicative CPU and memory tiers for self-hosting; they are vendor sizing recommendations, not independent benchmarks or guarantees:

Concurrent sessions	Indicative resources
5–10	2 CPU · 4 GB RAM
10–20	4 CPU · 8 GB RAM
20–50	8+ CPU · 16+ GB RAM

Use these only as an initial sizing clue. Benchmark representative target pages on the intended instance, container limits, and browser settings. Record throughput, CPU and memory at peak concurrency, timeout and crash rates, and the effect of retries. Include time for deployment, browser and operating-system updates, dependency maintenance, security controls, observability, capacity planning, and incident response in your cost model.

Chrome’s binary, its shared libraries, and browser-to-Puppeteer compatibility are part of the deployment. The standard Puppeteer package downloads a compatible Chrome for Testing binary by default; Puppeteer Core does not download Chrome and is intended for remote connections or separately managed browsers. See the Puppeteer installation guide.

Puppeteer’s official Docker image includes Chrome for Testing and required dependencies. Its documented sandbox-mode invocation uses the SYS_ADMIN capability and recommends an init process to manage browser processes. Follow the current Puppeteer Docker guide and your platform’s security model rather than copying container flags without review.

Browserless also publishes an open-source Docker image with Puppeteer and core APIs. Its documentation describes the image as free under SSPL-1.0 and says additional commercial licensing applies to closed-source commercial products or CI systems. Review the current license and deployment fit before selecting it. A reachable deployment without a TOKEN leaves endpoints unauthenticated; the /function endpoint can execute Puppeteer code supplied in request bodies. Do not expose an unauthenticated instance to an untrusted network. See the Browserless deployment documentation and verify the current license terms.

Compare both options fairly

Put these inputs in one worksheet. Estimate managed usage from measured sessions, and estimate self-hosting from a representative load test plus actual provider pricing and labor assumptions.

Input	How to use it
Monthly jobs and retries	Count test executions and additional connections caused by retries or reconnects.
Session duration distribution	Keep per-session durations or buckets, then round each Browserless session upward to 30 seconds.
Peak concurrency	Check Browserless’s plan limit; benchmark self-hosted capacity at the same peak.
Browserless plan and unit rate	Use the current selected plan allowance, price, overage rate, and any feature consumption.
Self-hosted provider and region	Price the measured instance or container capacity, storage, network, and orchestration actually required.
Engineering and operations time	Estimate setup, patches, security, monitoring, scaling, and incident response using your organization’s own labor assumptions.
Operational constraints	Consider data location, required browser versions, network access, security boundary, scaling behavior, and tolerance for queues.

Do not publish a break-even screenshot count from plan prices and sizing tiers alone. It depends on the actual session-time distribution, concurrency, provider and region, utilization, resource measurements, and how the organization values operational work. The available research does not establish an apples-to-apples regional compute estimate or an independent Browserless-versus-self-hosted total-cost study.

Performance and reliability considerations

Close sessions promptly. This stops idle Browserless browser time from accumulating and releases self-hosted capacity.
Bound waits and sessions. Set navigation, selector, and overall job timeouts. Record whether a timeout came from page readiness, browser startup, or the remote connection.
Control concurrency. A queue with a known worker limit helps avoid oversubscribing memory or exceeding a managed plan’s concurrent-browser allowance.
Track retries distinctly. Retrying can improve completion rates but adds browser work and may create fresh Browserless connections. Cap retries and preserve the original error.
Use representative pages. Heavy scripts, large images, animations, fonts, and third-party requests can materially change render time and resource demand.
Pin and update deliberately. Record Puppeteer and browser versions. In self-hosted environments, validate version changes against screenshots and dependencies before rollout.
Keep evidence for failed captures. Save the URL, timestamps, error type, browser version, and relevant console or network diagnostics while avoiding secrets in logs.

Troubleshooting common cost and capture problems

Symptom	Likely cause	Fix
More Browserless units than the screenshot count	Sessions crossed 30-second boundaries, remained idle, reconnected, or used proxies/CAPTCHA solving.	Measure actual connection lifetimes, close promptly, count reconnects, and inspect the unit breakdown in the current documentation.
Unit estimate differs from actual usage	The estimate used an average duration or omitted partial-block rounding and additional unit-consuming activity.	Calculate `ceil(seconds / 30)` for each connection; include reconnects and applicable proxy or CAPTCHA units.
Plan has enough units but jobs fail to start	Peak concurrent browsers exceed the plan limit, or sessions have not been closed.	Inspect active sessions, ensure all code closes its browser, and queue jobs below the plan’s current concurrency limit.
`Could not find expected browser locally`	The browser download did not run, cache location is unavailable, or installation scripts were blocked.	Install the browser with the package-manager command supported by the current Puppeteer guide, or set a writable `PUPPETEER_CACHE_DIR`.
Chrome exits with missing-library errors	The host or container lacks Chrome’s required shared libraries or fonts.	Use Puppeteer’s supported Docker image or install dependencies for the target operating system; verify against the current troubleshooting guide.
`No usable sandbox` or sandbox startup failure	Container or host sandbox configuration is incompatible with Chrome.	Configure the supported sandbox and permissions for the environment. Avoid disabling the sandbox as a routine production fix; Puppeteer warns against it.
`chrome_crashpad_handler: --database is required`	Chrome cannot write its profile or cache in a read-only container or inaccessible directory.	Provide writable temporary/config/cache and user-data directories owned by the browser process.
Screenshot hangs waiting for network idle	The page keeps network requests active or the readiness condition does not fit the page.	Wait for a meaningful selector or page state, set a deadline, and capture diagnostic information on timeout.
Container accumulates zombie browser processes	Browser child processes are not being reaped cleanly.	Use an init process as recommended by the Puppeteer Docker guide and ensure every browser closes in a `finally` path.

Primary references: Puppeteer troubleshooting, Puppeteer Docker guide, and Browserless unit consumption.

Or skip the browser setup

If your goal is to capture a page rather than operate a browser fleet, ScreenshotNeo is a website screenshot API and MCP server: one GET request returns an image or PDF. It can remove cookie and consent banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and responses identify page verdict and billing status in headers. Its MCP server provides screenshot tools for AI agents.

For a clean screenshot API with no browser installation to maintain, try ScreenshotNeo first. The service has 63 options, including full-page or CSS-element capture, device and viewport settings, dark mode, custom CSS and JavaScript, waits, headers and cookies, caching, PDF output, and bulk capture. See the ScreenshotNeo API documentation for available parameters and options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as image:
    image.write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.

FAQ

Can I convert a Browserless unit allowance directly into a screenshot count?

Only if you know the session-duration distribution and other unit usage. Each connection rounds up separately to 30-second units, so screenshots with different runtimes do not have one fixed unit cost.

Does self-hosting mean Chrome is free?

It avoids Browserless cloud usage charges, but the browser still consumes compute and requires installation, dependencies, security, updates, and operations. Price those from your own measured deployment and labor assumptions.

Is Browserless always cheaper below a particular volume?

The available sources do not establish a universal break-even point. Calculate both options from the same workload and explicit hosting and labor assumptions.

Does the Browserless self-hosting resource table guarantee a concurrency level?

No. It is vendor guidance for initial sizing. Validate target pages and concurrency on the actual environment.

Can an AI agent request screenshots without managing Puppeteer?

ScreenshotNeo offers an MCP server with screenshot, page-info, and PDF tools for MCP clients. Setup and available options are documented at its documentation.