ScreenshotNeo

BlogComparisons

BrowserCat vs ScreenshotAPI for Capturing Web Pages as Images

Compare BrowserCat’s managed browser sessions with ScreenshotAPI’s URL-to-image endpoint, including workflows, code, billing, and which tool fits your capture job.

By the ScreenshotNeo team4 October 202613 min read

BrowserCat and ScreenshotAPI can both help capture web pages, but they expose different workflows. ScreenshotNeo is the first alternative to evaluate if you want a direct screenshot API with clean captures: it accepts cookie banners like a visitor, removes 60+ known consent platforms, newsletter popups, and chat widgets, and bills only clean shots. For the two services in this comparison, choose BrowserCat when you need a managed browser session that your Playwright, Puppeteer, or CDP code can control. Choose ScreenshotAPI when you want to send a URL to an HTTP endpoint and receive rendered image bytes.

That is a product-fit recommendation based on the vendors’ documented workflows, not a benchmark. Their billing units also differ, so a “credit” from one service cannot be compared directly with a credit from the other.

1. Quick comparison

Question BrowserCat ScreenshotAPI.to
What do you connect to? A managed browser session, driven through Playwright, Puppeteer, or a CDP client. A screenshot REST endpoint. Send a URL and receive image data in the response.
How much control do you get? Browser automation control: navigate, interact, and capture using your browser library. Documented screenshot parameters for render options such as output format, viewport or full page, waiting, and page adjustments.
How is usage counted? Utility API: one credit per successful request. Websocket: one credit per 30 seconds of activity, rounded up. One credit per successful screenshot request, according to its docs and pricing page.
What is the pricing information available here? The reviewed materials describe free access and usage-based billing, but do not provide a complete current numerical plan schedule. The vendor-published pricing page lists a free tier and monthly subscriptions. See the cost section and check the live page before buying.
Likely fit Teams that need to drive a browser as part of automation. Teams that need a direct URL-to-image API.

BrowserCat describes routing browser sessions to managed backends, with automatic failover and the option to use Playwright, Puppeteer, or CDP clients. These are vendor descriptions, not independently measured availability or latency results. BrowserCat product overview · BrowserCat FAQ

ScreenshotAPI.to documents a REST workflow backed by headless Chromium. Its docs say the image is returned directly and is not stored on its servers. ScreenshotAPI documentation

2. Which one should you choose?

Choose BrowserCat when the screenshot is one step in browser automation

Use BrowserCat as a candidate when your job needs browser actions before the capture: sign in, navigate through a sequence, fill a form, inspect page state, or reuse existing Playwright/Puppeteer logic. BrowserCat provides a managed browser connection; your automation code still controls the browser. Its FAQ lists Playwright, Puppeteer, and CDP-based libraries as supported and says Selenium and Cypress are not currently supported. Confirm current compatibility and connection details in its live docs.

For a single static page capture, a browser session may mean maintaining more code and session lifecycle than an endpoint call. That tradeoff depends on your app and existing automation infrastructure.

Choose ScreenshotAPI when the input is a URL and the output is an image

Use ScreenshotAPI.to as a candidate when your application can provide a URL plus render options and simply needs the image bytes. Its docs list PNG, JPEG, WebP, and PDF, along with viewport and full-page capture, smart waiting, dark mode, ad blocking, cookie-banner removal, and other render controls. Check the current endpoint reference for the exact parameter names and limits before implementing.

This direct workflow can be simpler for thumbnails, page previews, and scheduled captures where you do not need to write browser interaction code. If a page requires a login flow or multi-step interaction that the endpoint does not cover with documented options, evaluate a browser-session workflow.

Try ScreenshotNeo first if you want a direct screenshot service with clean output

ScreenshotNeo is a website screenshot API and MCP server. It is designed to accept cookie or consent banners like a visitor and remove 60+ known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. It bills only clean shots: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and each response identifies the page verdict and billing status. Every feature is available on every plan. See ScreenshotNeo’s API documentation for parameters and setup.

3. Capture a page with BrowserCat

BrowserCat’s documented workflow is to connect an automation library to its managed browser endpoint and use that library to navigate and capture. The concrete endpoint and credentials are account-specific; use the connection string supplied by BrowserCat rather than hard-coding an invented host.

  1. Create or use a BrowserCat account and retrieve the Websocket connection endpoint from its current dashboard or quick-start docs.
  2. Install Playwright for your language and store that endpoint in an environment variable.
  3. Connect, open the target page, wait for the page state your job requires, and save a screenshot.
  4. Close the browser and context in a finally block so failures do not leave sessions running longer than needed.

Runnable Python example using Playwright. Set BROWSERCAT_WS_ENDPOINT to the connection endpoint supplied for your BrowserCat account:

import asyncio
import os
from pathlib import Path
from playwright.async_api import async_playwright

async def main():
    endpoint = os.environ["BROWSERCAT_WS_ENDPOINT"]
    async with async_playwright() as p:
        browser = await p.chromium.connect_over_cdp(endpoint)
        try:
            context = await browser.new_context(viewport={"width": 1440, "height": 1000})
            page = await context.new_page()
            response = await page.goto("https://example.com", wait_until="networkidle", timeout=60000)
            if response is None or not response.ok:
                status = None if response is None else response.status
                raise RuntimeError(f"Navigation failed; HTTP status: {status}")
            await page.screenshot(path="browsercat-shot.png", full_page=True)
            await context.close()
        finally:
            await browser.close()

asyncio.run(main())

Install the dependency with python -m pip install playwright. The endpoint connection method, browser protocol, and endpoint format should match the current BrowserCat instructions for your account. BrowserCat says it supports Playwright, Puppeteer, and CDP libraries; use its official quick start for the current connection recipe: BrowserCat quick start.

For Puppeteer, the same pattern applies: connect using BrowserCat’s current endpoint, create a page, navigate, wait for the required state, and call page.screenshot(). Use the current endpoint details and connection options in the official docs rather than copying an endpoint from another account.

4. Capture a page with ScreenshotAPI.to

ScreenshotAPI.to uses a GET request to its documented screenshot endpoint. The response body contains the image bytes, so write it to a file or stream it to your storage layer. The examples below use the documented endpoint and basic URL parameter. Consult the endpoint reference for authentication and optional rendering parameters for your account.

cURL

curl --fail --show-error --get \
  "https://screenshotapi.to/api/v1/screenshot" \
  --data-urlencode "url=https://example.com" \
  --output screenshot.png

Python

import requests

response = requests.get(
    "https://screenshotapi.to/api/v1/screenshot",
    params={"url": "https://example.com"},
    timeout=(10, 90),
)
response.raise_for_status()
content_type = response.headers.get("content-type", "")
if not content_type.startswith("image/"):
    raise RuntimeError(f"Expected image response, received {content_type!r}")
with open("screenshot.png", "wb") as image_file:
    image_file.write(response.content)
print("Screenshot ID:", response.headers.get("x-screenshot-id"))
print("Credits remaining:", response.headers.get("x-credits-remaining"))

Install the dependency with python -m pip install requests. Add the API key or token using the authentication method specified in your account’s current ScreenshotAPI docs; the minimal example omits credentials because the dossier does not specify the authentication parameter.

Node.js

import { writeFile } from "node:fs/promises";

const url = new URL("https://screenshotapi.to/api/v1/screenshot");
url.searchParams.set("url", "https://example.com");
const response = await fetch(url, { signal: AbortSignal.timeout(90000) });
if (!response.ok) {
  throw new Error(`Screenshot request failed: HTTP ${response.status}`);
}
const contentType = response.headers.get("content-type") ?? "";
if (!contentType.startsWith("image/")) {
  throw new Error(`Expected image response, received ${contentType}`);
}
await writeFile("screenshot.png", Buffer.from(await response.arrayBuffer()));
console.log("Screenshot ID:", response.headers.get("x-screenshot-id"));
console.log("Credits remaining:", response.headers.get("x-credits-remaining"));

As with Python, add authentication exactly as specified in the current vendor docs. For production, use the vendor’s SDK if it suits your stack; ScreenshotAPI’s docs list SDKs for JavaScript, Python, Go, Ruby, and PHP.

5. Compare capture options before migrating

A browser automation API and a screenshot endpoint expose different controls. Make a small requirements checklist before selecting one:

  • Page scope: viewport screenshot or full-page image? Full-page captures may involve lazy-loaded content and longer renders.
  • Wait condition: navigation complete, a specific selector, a fixed delay, or network idle? Sites with long-lived requests can make network-idle waits unsuitable.
  • Page state: must you click, log in, dismiss a dialog, or set storage before capture? Browser automation can express sequences directly; endpoint support depends on its documented controls.
  • Output: PNG, JPEG, WebP, or PDF? Confirm transparency and quality requirements as well as the downstream consumer’s supported formats.
  • Rendering: viewport size, device scale, dark mode, locale, timezone, fonts, and animations can change the result.
  • Network and access: does the page require cookies, custom headers, authorization, a proxy, or access to a private network?
  • Cleanup: should consent banners, newsletter modals, ads, or chat widgets be visible? Check whether the vendor supports the specific cleanup behavior you need.
  • Retention: does the service store output, and for how long? ScreenshotAPI.to’s docs state that captures are returned directly and not stored on its servers; verify current terms for your use case.

ScreenshotAPI.to documents format, full-page, wait, dark-mode, ad-blocking, cookie-banner, and PDF options. BrowserCat gives your automation code access to a managed browser session. A feature-by-feature parity assumption would be misleading: map each required behavior to the relevant current documentation before switching.

6. Billing and cost planning

BrowserCat counts requests or active browser time

According to BrowserCat’s FAQ, one successful Utility API request costs one credit. Websocket sessions cost one credit per 30 seconds of activity, rounded up. A screenshot-only task that uses a browser session should account for session setup, page loading, waiting, interaction, and screenshot time—not just the moment the image is saved. The amount billed depends on the actual API and session pattern.

BrowserCat describes usage-based billing, soft and hard usage limits, and overages. The reviewed FAQ says the defaults vary by account and plan, so inspect the live dashboard and current billing terms before running a large batch. This research did not capture a complete current numerical plan table for BrowserCat.

ScreenshotAPI.to counts successful screenshots

The ScreenshotAPI.to pricing page accessed for this article lists 200 screenshots per month free, then Starter at $19/month for 5,000, Growth at $49/month for 25,000, and Scale at $149/month for 100,000. It also lists pay-as-you-go credit packs and says pack credits do not expire. The vendor says failed captures are not charged and full-page and viewport captures each use one credit. These are vendor-published terms and may change; confirm the live pricing page before purchase.

Estimate workload as URLs × captures per URL per period, then include retries and scheduled refreshes. For example, 100 pages captured once daily means about 3,000 successful captures in a 30-day month before retries. This is arithmetic, not a recommendation for a particular plan. Also consider the cost of your own storage, image transfer, and any browser-side work in your application.

Do not compare credit totals directly

A BrowserCat Websocket credit represents a rounded 30 seconds of activity; ScreenshotAPI.to describes a credit as one successful screenshot. Compare the expected monthly bill for the exact workload and endpoint type, not the number of credits printed in plan tables.

7. Performance and reliability

No controlled cross-vendor benchmark is available in the research for this article, so it cannot establish which service is faster or more reliable. BrowserCat describes backend routing and automatic failover; treat those as vendor claims, not a guarantee for your particular target site. ScreenshotAPI.to returns image bytes from a real-time browser render, and documents response metadata including screenshot ID and duration. The values for your URLs will depend on page weight, scripts, network conditions, waits, and capture size.

For reliable production capture:

  • Set explicit connection and response timeouts.
  • Check HTTP status and response content type before saving bytes.
  • Use a bounded retry policy for transient failures, with backoff and jitter. Avoid retrying invalid URLs, authentication failures, or other permanent errors unchanged.
  • Record the target URL, request options, status, elapsed time, and vendor request or screenshot ID for diagnosis. Redact secrets and sensitive query parameters.
  • Limit concurrency to a level your plan, application, and target websites can support.
  • Use stable wait conditions. A selector that marks the content ready is often more deterministic than an arbitrary long sleep.
  • Test representative pages, including very long pages, client-rendered apps, and pages with delayed images or fonts.
  • Use caching when the screenshot does not need to reflect every request’s latest page state; make the cache policy explicit.

Browser sessions need lifecycle handling: always close contexts and browsers, including error paths. Direct image endpoints avoid managing those browser objects in your application, but your client still needs to handle HTTP errors, timeouts, and binary data correctly.

8. Troubleshooting

Symptom Likely cause What to check
BrowserCat connection fails Wrong endpoint, missing credentials, or a connection method that does not match the account’s endpoint. Copy the current endpoint from the account/dashboard docs, confirm the expected Playwright/Puppeteer/CDP connection API, and keep credentials in environment variables.
BrowserCat session costs more than expected Websocket billing rounds activity up in 30-second units; a slow navigation or long wait can cross another unit. Measure full session duration, shorten unnecessary waits, close the browser promptly, and check whether the Utility or Websocket API matches the job.
Screenshot is blank or incomplete The page may render content after the chosen wait condition, require interaction, or fail to load required resources. Wait for a content-specific selector, verify navigation status, and inspect the page through the same browser workflow.
Full-page screenshot misses images Images may be lazy-loaded below the viewport or injected after initial page load. Scroll through the page before capture or use a documented full-page/lazy-image option if available. Verify on the target site.
ScreenshotAPI response is not an image The service returned an error response, often due to an invalid request or failed capture. Check the HTTP status and response body before writing the response to a .png file. Log the screenshot ID when present.
ScreenshotAPI request times out The page is slow, a wait condition does not complete, or the client timeout is shorter than the render time. Use a realistic timeout, reduce unnecessary waiting, and retry only transient failures with a bounded backoff.
Unexpected crop or dimensions Viewport and full-page capture have different dimensions; device scale and page layout also affect output size. Set the intended viewport and output options explicitly, then inspect image dimensions in your pipeline.
Unexpected cookie or popup in the image Cleanup may be unavailable, disabled, or unable to recognize that particular widget. Check the service’s current cleanup options. With browser automation, dismiss the known dialog in code when allowed by the site.
Too many failed retries Retries are repeating permanent errors or adding load during an outage. Classify failures, cap attempts, apply backoff, and send persistent failures to a review queue.

9. Or skip the browser setup

ScreenshotNeo turns a URL into a screenshot with one GET request. It accepts cookie banners like a visitor, then removes cookie and consent banners, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses include X-Page-Verdict and X-Billed headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

cURL

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

Python

import requests

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

Node.js

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

See the ScreenshotNeo docs for its API options. It supports full-page and selector captures, device presets and custom viewports, retina scale, image and PDF output, CSS/JavaScript injection, click and wait actions, request blocking, custom headers and cookies, timezone and geolocation, caching, signed image links, async jobs with signed webhooks, bulk capture, and a usage API. It also accepts parameter names used by other screenshot APIs to make migration easier.

There is a free allowance of 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000; higher listed plans include $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Sign up free for 1,000 screenshots a month, with no card.

10. FAQ

Can both services capture a full web page?

ScreenshotAPI.to documents full-page capture. With BrowserCat, use the screenshot method from your chosen browser automation library and check its behavior for the page and browser configuration you use.

Does ScreenshotAPI.to store the images it generates?

Its documentation says screenshots are returned in the response and not stored on its servers. Review current vendor terms for your data-handling requirements.

Does BrowserCat support Selenium or Cypress?

Its reviewed FAQ says it supports Playwright, Puppeteer, and CDP-based libraries, and does not currently support Selenium or Cypress. Confirm the live FAQ in case support has changed.

Can I treat failed requests as free?

ScreenshotAPI.to says failed captures are not charged. BrowserCat’s FAQ describes a successful Utility API request as one credit; its Websocket billing is based on activity duration. Check the current terms for the specific API you use.

Is there a universal winner?

No. The central decision is whether your application needs a browser session it can control or a direct screenshot endpoint. Compare the required page actions, options, error behavior, and monthly bill for your workload.

Sources