Browserless Screenshot API vs ScreenshotOne: Which Should You Use?

Short answer: choose Browserless when screenshots are one part of a larger browser automation workload, especially if you want to reuse Puppeteer or Playwright code, keep browser sessions, or consider self-hosting. Choose ScreenshotOne when you want a screenshot-focused managed API and its rendering, output, caching, integrations, and production workflow fit your needs. There is no universal winner: test the pages you actually need and compare total cost at your expected volume.

If you are evaluating a third option, try ScreenshotNeo first: it removes cookie banners, popups, and chat widgets before capture, and bills only clean shots.

This comparison uses provider documentation and published pricing. It is not a head-to-head benchmark; results depend on the target pages and settings. Browserless screenshot documentation, ScreenshotOne pricing.

1. The decision at a glance

Choose	When it fits	What to verify
ScreenshotNeo	You want a screenshot API with consent-banner, newsletter-popup, and chat-widget removal; clear page verdict and billing headers; or an MCP server for AI agents.	Run your target URLs with your needed rendering options and check whether the output and API fit your workflow.
Browserless	Screenshots are part of a browser automation system; you want Puppeteer-style REST options, existing Puppeteer or Playwright code, persistent sessions, or a self-hosting path.	Browser time and unit usage, browser/session needs, deployment and operations, and how it handles your difficult pages.
ScreenshotOne	You want a managed service centered on screenshots, PDFs, caching, storage, webhooks, and a documented production workflow.	Quota, request rate, plan-gated features, overage settings, and whether its rendering controls match your pages.
Self-managed Puppeteer or Playwright	You need a local script, test, or low-volume internal capture and are prepared to operate the browser setup.	Browser installation and updates, queues, concurrency, retries, storage, monitoring, and failure handling.

Browserless’s REST screenshot endpoint accepts a URL or inline HTML and returns PNG, JPEG, or WebP. Its REST API is intended for stateless browser tasks; its BaaS v2 route supports existing Puppeteer or Playwright code and persistent sessions. Browserless also documents cloud and Docker self-hosting options. Browserless REST screenshot API, REST API overview, open-source Docker deployment.

ScreenshotOne publishes a screenshot quota model and lists PDF and HTML rendering, full-page captures, caching, S3 uploads, webhooks, signed links, and integrations on Basic. Its higher plans add capabilities including IP location selection, scrolling screenshots, video generation, and GPU rendering. Confirm current availability and plan terms before choosing. ScreenshotOne pricing and plan features.

2. Browserless: a runnable screenshot request

Browserless uses a POST request to /screenshot. Put the API token in the query string and send a JSON body containing url and options. The examples below save the response bytes as an image. Store the token in an environment variable rather than committing it to source control.

cURL

export BROWSERLESS_TOKEN='YOUR_API_TOKEN'
curl --fail-with-body --silent --show-error \
  -X POST "https://production-sfo.browserless.io/screenshot?token=${BROWSERLESS_TOKEN}" \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  --data '{"url":"https://example.com/","options":{"fullPage":true,"type":"png"}}' \
  --output screenshot.png

Python

import os
import requests

url = "https://production-sfo.browserless.io/screenshot"
token = os.environ["BROWSERLESS_TOKEN"]
payload = {
    "url": "https://example.com/",
    "options": {"fullPage": True, "type": "png"},
}
response = requests.post(
    url,
    params={"token": token},
    headers={
        "Cache-Control": "no-cache",
        "Content-Type": "application/json",
    },
    json=payload,
    timeout=90,
)
response.raise_for_status()
with open("screenshot.png", "wb") as output:
    output.write(response.content)

Node.js

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

const token = process.env.BROWSERLESS_TOKEN;
if (!token) throw new Error('Set BROWSERLESS_TOKEN');

const endpoint = new URL('https://production-sfo.browserless.io/screenshot');
endpoint.searchParams.set('token', token);
const response = await fetch(endpoint, {
  method: 'POST',
  headers: {
    'Cache-Control': 'no-cache',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://example.com/',
    options: { fullPage: true, type: 'png' },
  }),
  signal: AbortSignal.timeout(90_000),
});
if (!response.ok) {
  throw new Error(`Browserless returned ${response.status}: ${await response.text()}`);
}
await writeFile('screenshot.png', Buffer.from(await response.arrayBuffer()));

Capture inline HTML instead of a URL

Send html in the JSON body when rendering markup you supply. Do not send url in that same request.

{
  "html": "<html><body><h1>Hello</h1></body></html>",
  "options": { "fullPage": true, "type": "png" }
}

3. Browserless options and capture behavior

Browserless documents Puppeteer-style screenshot settings in the options object. The endpoint also supports request-level controls for selector capture, scrolling, and page setup. Check its live API reference for the complete schema and accepted values.

Need	Setting or approach	Practical note
Entire document	`options.fullPage: true`	For lazy-loaded content, use the request-level `scrollPage: true` to scroll before capture, then combine with full-page capture.
One element	Top-level `selector`	The API waits for the element and captures its bounds. Use `options.clip` for a fixed rectangle instead.
Viewport and device scale	`options.viewport`, `options.deviceScaleFactor`	Set dimensions and scale deliberately; larger viewports and scale factors produce larger images and can require more memory.
Format	`options.type`: PNG, JPEG, or WebP	Set file extension to match the actual response format.
JPEG or WebP quality	`options.quality`	Quality does not apply to PNG. Confirm accepted range and format behavior in the current API reference.
Wait for content	Navigation settings, selector waits, or an explicit wait strategy	Prefer waiting for the meaningful content selector over a long fixed delay when the page provides a stable marker.
Modify page before capture	`addScriptTag`, `addStyleTag`	Use this for controlled visual changes. Do not use injected scripts to bypass a site’s access controls.
Filter requests	`rejectResourceTypes`, `rejectRequestPattern`	Blocking resources can speed rendering, but blocking fonts, scripts, or images may alter the result.
Continue through some wait failures	`bestAttempt`	Use only when partial output is useful; it can conceal a page that did not reach the intended state.

Browserless warns that automation defenses can produce blank captures, CAPTCHA pages, access-denied content, or missing elements. A screenshot endpoint cannot guarantee access to every site. Follow the target site’s terms and permissions; test authenticated or location-sensitive pages with authorized credentials and the expected network location. Browserless screenshot API and troubleshooting notes.

4. ScreenshotOne: how to evaluate it

ScreenshotOne is the screenshot-first candidate in this comparison. Its official pricing page currently lists 100 free screenshots, then Basic at $17/month for 2,000 screenshots, Growth at $79/month for 10,000, and Scale at $259/month for 50,000. The listed request rates are 40, 80, and 150 per minute respectively; listed extra-use rates are $0.009, $0.006, and $0.004 per screenshot. Prices exclude VAT. These are published plan figures and may change. Check current ScreenshotOne pricing.

For a fair evaluation, map each requirement to the current documentation and your plan. Check output type, full-page and dynamic-page behavior, waiting controls, caching, storage, webhook delivery, signed links, and rate limits. The listed Basic features include PNG, WebP, JPEG, PDF, HTML rendering, full-page capture, caching, S3 upload, webhooks, signed links, integrations, and stealth mode. Growth lists IP location selection, scrolling screenshots, and video; Scale lists GPU rendering and priority support. Do not assume a feature is included based on an older comparison.

ScreenshotOne says only successful requests count toward its quota, with caveats for caching: cache hits do not count, while a cache miss may result in another render. A successful image with visual defects may still count. Review the current pricing FAQ and credit documentation when modeling usage. Pricing FAQ, credits documentation.

5. Compare cost without mixing unlike units

ScreenshotOne’s published plans charge around a monthly screenshot allowance. Browserless’s provider-authored September 2026 comparison describes usage in units of up to 30 seconds of browser time. A unit is not automatically one screenshot: page weight, wait time, and browser work affect the comparison. The Browserless article says its pricing was checked August 6, 2026, so verify live terms before purchase. Browserless provider comparison and dated pricing.

Service	Published basis in the cited material	Cost-modeling question
Browserless	Provider comparison: $25/month billed annually for 20,000 units; one unit is up to 30 seconds of browser time; listed overage $0.002/unit.	How many browser-time units does your actual mix of pages and waits consume, and what happens at peak concurrency?
ScreenshotOne	Official page: $17/month for 2,000; $79 for 10,000; $259 for 50,000, with plan-specific listed extra rates.	How many successful unique uncached outputs do you need, and will you enable paid overages?
ScreenshotNeo	Free: 1,000 shots/month; Starter $5 for 3,000; Growth $15 for 15,000; Pro $39 for 60,000; Scale $99 for 250,000; Business $249 for 1,000,000. Yearly billing gives two months free.	Does the clean-shot billing model and included feature set match the pages and workflow you need?

Model the monthly bill as a workload, not just a plan headline. Count expected captures, retries, cache hits or misses, page wait time, output formats, and bursts. Include the cost of operating queues, browser updates, storage, monitoring, and on-call work if you self-host. No independent head-to-head performance or cost test is available here.

6. Run a useful evaluation before choosing

Build a representative URL set. Include a short static page, your longest page, a JavaScript-heavy page, a page with lazy-loaded images, and a page with a consent banner. Add authenticated or location-sensitive pages only when you are authorized to capture them.
Fix the capture specification. Use the same viewport, device scale, output format, full-page or selector target, and content-ready condition wherever each provider supports the equivalent.
Check correctness. Inspect whether the intended content rendered, whether images and fonts loaded, whether overlays obscure content, and whether the crop includes the expected element or full document.
Measure your own latency and errors. Record request duration, timeouts, rate-limit responses, blank pages, missing selectors, and retries. Do not infer a general benchmark from a small trial.
Model production volume. Include average and peak request rates, cache behavior, browser duration, retries, overages, and required storage or webhook processing.
Review operations and data handling. Decide who manages browser updates, session state, credentials, logs, storage, and network placement. Confirm each provider’s current terms for your use case.
Choose the simplest fit and rerun the sample after configuration changes. Keep a small regression set so changes to waits, viewport, or page behavior do not silently degrade output.

7. Reliability, performance, and integration trade-offs

Rendering and waits

A page reaching the browser’s load event does not necessarily mean its application content is ready. Prefer a stable selector or known page-state condition when available. Fixed delays can work for a known page but add latency and may still be too short during slow responses. For full-page captures, lazy-loaded content may need scrolling before the final image.

Concurrency and retries

Respect each plan’s current rate limits and any Browserless concurrency or unit limits. Use bounded retries with backoff for transient network or service errors, not for every failure. Avoid retrying a deterministic selector-not-found or access-denied response unchanged. Make downstream file writes idempotent so a retry does not create duplicate records.

Output and storage

PNG is useful when fidelity or transparency matters; JPEG and WebP can reduce file size when supported by the destination. Confirm that the response is successful before saving binary data, and keep the correct MIME type and extension. If you need S3 upload, signed delivery links, webhooks, or PDF output, check plan inclusion and delivery semantics in the live docs.

Browserless versus screenshot-first workflow

Browserless has more room to grow into multi-step browser work through Puppeteer or Playwright-compatible workflows and sessions. That control can be useful, but it also gives your application more browser lifecycle and failure behavior to handle. A screenshot-focused service can reduce the amount of browser infrastructure your application owns, but it may not suit workflows that need arbitrary interaction beyond its API options.

8. Troubleshooting

Symptom	Likely cause	Fix
HTTP error or authentication failure	Missing, invalid, or malformed token; wrong endpoint or deployment region.	Check the token and endpoint in the provider dashboard/docs. Keep tokens server-side and inspect the error body before saving a file.
Saved file is JSON or an error page, not an image	The client wrote an error response as binary output.	Check HTTP status and response content type before writing bytes; log the provider’s error response safely.
Blank or white screenshot	Navigation did not finish, the page requires interaction/authentication, scripts failed, or the site blocked automation.	Wait for a real content selector, verify authorized cookies/headers, and inspect whether the target displays a CAPTCHA or access-denied screen. Do not assume retries will defeat a site block.
Missing images below the fold	Lazy-loaded images were never triggered.	Scroll through the page before capture, then request full-page output. Check that image loading completes within the timeout.
Element selector not found	Selector is incorrect, content is in a frame/shadow tree, or the page is not ready.	Confirm the selector in a real browser, wait for the element, and verify the API’s selector scope and frame support.
Capture is clipped or unexpectedly tall	Full-page mode, viewport, element bounds, or fixed-position elements affect layout.	Compare viewport capture with full-page capture; use selector targeting for a single component or a clip rectangle for fixed coordinates.
Timeouts or inconsistent output	Slow third-party resources, long animations, unstable page state, or too much work at once.	Wait for a meaningful content condition, block only nonessential requests where supported, reduce concurrency, and use bounded retries for transient failures.
Rate limit or quota exceeded	Request burst exceeds plan limit or monthly allowance/hard limit.	Queue requests, smooth bursts, inspect usage and overage settings, or select a plan with sufficient capacity.
Cost differs from a simple request count	Browser time, cache misses, retries, overages, or differently priced outputs affect usage.	Measure actual workload and read current billing rules. Do not treat Browserless time units as screenshot counts.

9. Or skip the browser setup

If you want to compare a third managed screenshot API, ScreenshotNeo returns PNG, JPEG, WebP, or PDF from a single GET request. Its docs cover the ScreenshotNeo API 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)
open("shot.webp", "wb").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}`);

Cookie banners, popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed. Responses identify the page verdict and billing status in headers.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.

10. FAQ

Can Browserless capture a single element?

Yes. Its screenshot API accepts a top-level CSS selector and can also capture a fixed clip rectangle. See the endpoint documentation.

Are Browserless units and ScreenshotOne screenshots equivalent?

No. The cited Browserless comparison defines a unit as up to 30 seconds of browser time, while ScreenshotOne publishes screenshot quotas. Model each provider with your real pages and current pricing.

Does either service guarantee that a protected page will render?

No. Browserless documents cases where automation defenses lead to blank captures, CAPTCHA pages, or access-denied results. Test permitted pages and do not assume any provider can bypass every site’s protections.

Should I use a hosted API for a few screenshots?

Not necessarily. For a local one-off or small internal task, Puppeteer or Playwright may be enough if you are comfortable installing and maintaining the browser setup.

Can I make the final choice from published prices alone?

No. The billing units, included features, cache rules, and page behavior differ. Compare representative output and the total cost at your expected request volume.