Is BrowserCat Free for Bulk Website Screenshots?

Yes, BrowserCat has a free plan you can use for bulk screenshot automation. Its Hobby plan lists 1,000 credits per month and 1,000 concurrent requests. But BrowserCat does not state a screenshot-specific credit cost or guarantee a batch throughput, so 1,000 credits should not be read as a promise of 1,000 screenshots. The cost depends on which BrowserCat API you use and how long each browser session runs.

This guide shows how to estimate usage, capture a list of URLs with Playwright and BrowserCat, and avoid treating concurrency as a throughput guarantee. It also covers spend limits, failures, and an alternative for developers who want a direct screenshot API.

What BrowserCat’s free plan includes

BrowserCat’s pricing page lists the following terms for its Hobby plan. Check the current pricing page before starting a large job because pricing and limits can change.

Item	Hobby plan listing
Monthly price	$0
Included credits	1,000 per month
Concurrent requests	1,000
Extra credits	$0.0025 per credit
Free-plan soft limit	$10 by default
Free-plan hard limit	$20 by default

The credit unit depends on the interface:

• Utility API: one credit for a successful request.
• WebSocket browser session: one credit per 30 seconds of activity, rounded up.

Those rules do not establish a universal credit cost per screenshot. A screenshot made through a successful Utility API request may be charged differently from a screenshot produced during a longer WebSocket session. Confirm which route your implementation uses and monitor the account usage dashboard.

Estimate whether 1,000 credits will cover your batch

First identify the API path, then estimate the number of billable units using its documented credit rule. For WebSocket sessions, the rough estimate is:

credits per session = ceiling(session duration in seconds / 30)
estimated credits = sum of credits across sessions

For example, a 31-second WebSocket session uses two credit intervals under the stated rounding rule. This is a calculation from BrowserCat’s billing definition, not a claim that a screenshot takes 31 seconds. Session duration depends on navigation, page behavior, waits, and the work your script performs.

1. Count the URLs you plan to process and decide whether they will be captured sequentially or concurrently.
2. Determine whether the chosen endpoint charges per successful request or by WebSocket activity time.
3. For WebSocket usage, estimate session duration conservatively and round each session up to 30-second intervals.
4. Leave room for retries and slow pages. Failed attempts may still consume session time depending on when the failure occurs; check actual usage rather than assuming otherwise.
5. Run a small representative sample, inspect usage, and use that observed billing pattern to estimate the full job.

Do not infer a maximum screenshot count from the monthly credit allowance without knowing the billing path. Likewise, the listed 1,000 concurrent requests describe a concurrency ceiling on the pricing page, not guaranteed completion speed or a recommended worker count.

Capture multiple URLs with Playwright and BrowserCat

BrowserCat’s quick start demonstrates using Playwright with its managed cloud browser. The example below processes URLs one at a time, which makes it easier to observe failures and estimate usage before increasing concurrency. Install the Playwright package and follow BrowserCat’s current quick-start instructions for the required account, API key, and WebSocket connection URL: BrowserCat documentation.

import { chromium } from "playwright";

const apiKey = process.env.BROWSERCAT_API_KEY;
const browserWss = process.env.BROWSERCAT_WS_URL;

if (!apiKey || !browserWss) {
  throw new Error("Set BROWSERCAT_API_KEY and BROWSERCAT_WS_URL first.");
}

const urls = [
  "https://example.com/",
  "https://example.org/",
];

const browser = await chromium.connectOverCDP(browserWss);

try {
  const page = await browser.newPage();
  for (const [index, url] of urls.entries()) {
    try {
      const response = await page.goto(url, {
        waitUntil: "domcontentloaded",
        timeout: 45_000,
      });
      await page.screenshot({ path: `shot-${index + 1}.png`, fullPage: true });
      console.log(`${url}: captured (HTTP ${response?.status() ?? "unknown"})`);
    } catch (error) {
      console.error(`${url}: failed`, error);
    }
  }
} finally {
  await browser.close();
}

Use the connection URL and authentication format shown in your BrowserCat account or current documentation; do not publish API keys in source control. This script reuses a page and saves each result locally. For sites with slow client rendering, add a targeted wait after navigation rather than a long fixed delay for every URL.

Add concurrency gradually

Parallel workers can reduce elapsed time, but they also create more simultaneous sessions and make failures, rate limits, and spend harder to observe. BrowserCat’s Playwright testing guide includes a 50-worker configuration as an example and advises increasing concurrency gradually. That example is not a screenshot throughput result or a guarantee that a 50-worker batch will finish at a particular rate.

Start with a small worker count, capture a representative sample, then increase it in measured steps while checking completion rate, errors, session duration, and credit consumption. Keep concurrency below the documented account limit if other jobs share the account.

When the free plan is not enough

BrowserCat lists extra Hobby credits at $0.0025 each, alongside default free-plan soft and hard limits of $10 and $20. Its pricing page describes an approval step after the soft limit and request rejection at the hard limit if approval is not granted. Review the account’s current spend controls before launching a large unattended job, and do not assume requests will continue past a hard limit.

For a volume estimate, use the unit that applies to your API route, add a retry allowance, and compare the result with both the included monthly credits and the account’s spend protections. If the estimate is close to a limit, reduce concurrency or divide the batch so you can inspect usage between portions.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Make one GET request for a URL and receive a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for parameters and formats.

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 f:
    f.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}`);
await Bun.write("shot.webp", res);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000 screenshots. Sign up free for 1,000 screenshots a month, with no card.

Troubleshooting bulk captures

Problem	Likely cause	What to do
Authentication or connection fails	Missing or invalid key, or an incorrect WebSocket endpoint	Check the account’s current quick-start instructions and environment variables. Keep credentials out of logs and repositories.
Some URLs time out	Slow navigation, blocked resources, or a page that never reaches the selected load condition	Set an explicit timeout, use an appropriate navigation condition, and record failures by URL. Retry selectively rather than rerunning the whole batch.
Usage rises faster than expected	WebSocket activity is billed in rounded-up 30-second intervals; long-lived sessions or retries add time	Close sessions promptly, measure representative durations, inspect dashboard usage, and recalculate before continuing.
Requests are rejected partway through	A configured hard spend limit may have been reached, or account limits may apply	Inspect spend controls and account status. Split remaining work into smaller runs after resolving the limit.
High concurrency causes unstable results	Many sessions amplify site-side throttling and make resource pressure harder to diagnose	Lower worker count and increase it gradually while tracking errors and usage.
Screenshot is incomplete	The page may render below the initial viewport after navigation	Use full-page capture where needed and wait for the specific content your workflow requires.

Performance, reliability, and cost considerations

• Performance: concurrency may lower elapsed time, but page load time and session duration still drive the actual work. The pricing page’s concurrency figure alone cannot predict batch completion time.
• Reliability: isolate errors per URL, preserve a list of failures, and retry only those URLs. Use a small pilot to reveal login walls, bot checks, redirects, and unusually slow pages.
• Cost: estimate from the relevant credit rule, account for rounding and retries, and watch actual usage. Do not assume every screenshot has identical cost.
• Site impact: avoid sending a sudden burst to the same site. A lower worker count can reduce throttling and make failures easier to diagnose.

FAQ

Can I use BrowserCat without paying to start?

Yes. Its pricing page lists a $0 Hobby plan with 1,000 credits per month. Review the current terms and spend limits before running a large job.

Does 1,000 credits mean 1,000 screenshots?

Not necessarily. Utility API requests and WebSocket browser activity have different credit rules, and BrowserCat does not specify a universal screenshot credit cost in the reviewed material.

Does BrowserCat guarantee 1,000 simultaneous screenshot jobs?

The pricing page lists 1,000 concurrent requests. It does not establish a guaranteed screenshot throughput or completion rate.

Is the 50-worker example a recommended screenshot setting?

No. It appears in a Playwright testing guide as an example configuration, with advice to raise concurrency gradually. It is not a throughput guarantee.

Where can I check current limits?

Use BrowserCat’s live pricing page and documentation, and check your account dashboard for usage and spend controls.