Browserless vs ScrapingBee for Rendering Web Pages as Screenshots

Short answer: ScrapingBee is a fit when you want screenshot capture as part of its HTML scraping API; Browserless is a fit when you want a dedicated screenshot endpoint with Puppeteer-style capture controls. Neither has a documented universal advantage in screenshot accuracy, success rate, or cost. Compare them using representative pages and your expected request volume, rendering time, proxy use, and concurrency.

For developers who want a purpose-built screenshot API with one GET request, clean captures, and clear billing outcomes, ScreenshotNeo is the alternative to try first: cookie banners, popups, and chat widgets are removed before capture, and only clean shots are billed.

1. At a glance

Question	ScrapingBee	Browserless
API shape	Screenshot parameters on the HTML scraping API.	Dedicated POST /screenshot endpoint.
Screenshot rendering	Requires JavaScript rendering with render_js=True; screenshot mode loads images and CSS by disabling resource blocking.	Returns PNG, JPEG, or WebP; accepts a URL or inline HTML.
Capture scope	Viewport by default; full page or a CSS selector are available.	Viewport, full page, selector, or clip region.
Page preparation	Wait controls and JavaScript scenarios support synchronization and interactions.	Screenshot options include viewport, image waiting, clipping, and selector targeting; scrolling can trigger lazy loading.
Usage unit	API credits, with request cost varying by rendering and proxy configuration.	Browser-time units: one unit covers up to 30 seconds per browser connection; proxy traffic and successful CAPTCHA solves have separate unit costs.

These are documented capability differences, not measured performance results. The available vendor documentation does not establish which service renders more accurately or succeeds more often across real sites.

2. ScrapingBee screenshot workflow

ScrapingBee adds screenshot parameters to its HTML API. JavaScript rendering is mandatory for screenshots. With rendering enabled, screenshot capture costs at least 5 credits on the classic proxy configuration. Screenshot mode automatically disables resource blocking so page images and CSS can load.

Here is a runnable cURL request for a full-page screenshot. Replace the placeholder with your API key.

curl -G 'https://app.scrapingbee.com/api/v1/' \
  --data-urlencode 'api_key=YOUR_API_KEY' \
  --data-urlencode 'url=https://example.com' \
  --data-urlencode 'render_js=true' \
  --data-urlencode 'screenshot=true' \
  --data-urlencode 'screenshot_full_page=true' \
  -o page.png

The Python example uses the same query parameters and saves the response bytes:

import requests

response = requests.get(
    "https://app.scrapingbee.com/api/v1/",
    params={
        "api_key": "YOUR_API_KEY",
        "url": "https://example.com",
        "render_js": "true",
        "screenshot": "true",
        "screenshot_full_page": "true",
    },
    timeout=90,
)
response.raise_for_status()
with open("page.png", "wb") as image:
    image.write(response.content)

Node.js using built-in fetch:

const params = new URLSearchParams({
  api_key: 'YOUR_API_KEY',
  url: 'https://example.com',
  render_js: 'true',
  screenshot: 'true',
  screenshot_full_page: 'true',
});

const response = await fetch(`https://app.scrapingbee.com/api/v1/?${params}`);
if (!response.ok) {
  throw new Error(`ScrapingBee returned ${response.status}: ${await response.text()}`);
}
const fs = await import('node:fs/promises');
await fs.writeFile('page.png', Buffer.from(await response.arrayBuffer()));

Useful ScrapingBee screenshot parameters

• screenshot=true: request an image response. It requires render_js=true.
• screenshot_full_page=true: capture the full page instead of just the viewport.
• screenshot_selector: target a CSS-selected portion of the page.
• window_width and window_height: choose the browser viewport; this can change responsive layout and the visible content.
• wait, wait_for, and wait_browser: give rendering time or synchronize with page state. Use the least wait that reliably covers the page’s rendering behavior.
• JavaScript scenarios: perform actions such as clicks or scrolling before capture. These are useful when the page requires interaction; they are not screenshot-only settings.
• Proxy and geolocation settings: choose the documented proxy behavior appropriate to the target. They can affect both access and credit consumption.

ScrapingBee documents JavaScript rendering as enabled by default for its HTML API, but set render_js=true explicitly in screenshot requests so the requirement is clear. Use the API response and account usage details to confirm the effective configuration and credit use.

3. Browserless screenshot workflow

Browserless provides a dedicated POST /screenshot endpoint. The request supplies a URL and screenshot options; its documented options include format, full-page capture, viewport dimensions, quality, clipping, device scale factor, and selector capture. The API can also accept inline HTML in place of a URL.

The endpoint is account and deployment specific. Use the URL and authentication format from your Browserless account or deployment documentation. This request shape illustrates the documented endpoint and options; supply the endpoint’s required token or authorization as configured for your account.

curl -X POST 'https://YOUR_BROWSERLESS_ENDPOINT/screenshot?token=YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "https://example.com",
    "options": {
      "fullPage": true,
      "type": "png",
      "viewport": {"width": 1365, "height": 900},
      "deviceScaleFactor": 1
    }
  }' \
  -o page.png

Python with requests:

import requests

endpoint = "https://YOUR_BROWSERLESS_ENDPOINT/screenshot"
response = requests.post(
    endpoint,
    params={"token": "YOUR_TOKEN"},
    json={
        "url": "https://example.com",
        "options": {
            "fullPage": True,
            "type": "png",
            "viewport": {"width": 1365, "height": 900},
            "deviceScaleFactor": 1,
        },
    },
    timeout=90,
)
response.raise_for_status()
with open("page.png", "wb") as image:
    image.write(response.content)

Node.js:

const endpoint = new URL('https://YOUR_BROWSERLESS_ENDPOINT/screenshot');
endpoint.searchParams.set('token', 'YOUR_TOKEN');

const response = await fetch(endpoint, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    url: 'https://example.com',
    options: {
      fullPage: true,
      type: 'png',
      viewport: { width: 1365, height: 900 },
      deviceScaleFactor: 1,
    },
  }),
});
if (!response.ok) {
  throw new Error(`Browserless returned ${response.status}: ${await response.text()}`);
}
const fs = await import('node:fs/promises');
await fs.writeFile('page.png', Buffer.from(await response.arrayBuffer()));

Check your Browserless endpoint documentation for exact deployment-specific request fields and authentication. Its screenshot endpoint sits alongside separate content, scraping, PDF, download, and custom-function endpoints. REST calls are not a real-time interactive session with branching while the page runs.

Useful Browserless capture options

• Image type: select PNG, JPEG, or WebP as supported by the endpoint.
• fullPage: extend capture beyond the initial viewport.
• viewport: set width and height before capture; responsive page layout depends on this choice.
• quality: configure lossy image quality where applicable.
• clip: capture a rectangular region.
• selector: capture the bounding box of a selected element.
• deviceScaleFactor: control output pixel density relative to the CSS viewport.
• waitForImages: wait for images where supported by the BAP guide.
• scrollPage: scroll to trigger lazy-loaded material; it can be combined with full-page capture.

4. Which service fits which workload?

Choose based on	ScrapingBee may fit when…	Browserless may fit when…
Existing integration	You already use its HTML scraping API and want image output in that workflow.	You want a separate endpoint dedicated to screenshot capture.
Page handling	You need API wait controls, JavaScript scenarios, or proxy/geolocation settings in a scraping workflow.	You need controls such as clipping, a selector bounding box, viewport, or image format in a browser endpoint.
Beyond screenshots	You need HTML scraping and screenshot output from the same API surface.	You may also need its separate browser task endpoints or hosted browser automation.
Blocked sites	You need to evaluate the available proxy configuration against your target pages.	You want to evaluate the documented unblock API or proxy options against your target pages.
Billing model	Your estimates are naturally per request/configuration and API credit.	Your estimates are naturally based on browser connection time, proxy traffic, and concurrency.

Neither vendor documentation promises that every bot check can be bypassed. A proxy or unblock feature is a mitigation to evaluate on sites you are permitted to access, not a guarantee of access or identical output.

5. Pricing and workload economics

The published figures below were recorded from vendor pages in 2026. Pricing, quotas, and billing conditions can change; verify the linked vendor pages before purchasing. The figures are not directly comparable because the services meter different work.

ScrapingBee credit costs

Its documented request cost varies by rendering and proxy setup:

• Classic proxy without JavaScript rendering: 1 credit.
• Classic proxy with JavaScript rendering: 5 credits.
• Premium proxy without JavaScript rendering: 10 credits.
• Premium proxy with JavaScript rendering: 25 credits.
• Stealth proxy with JavaScript rendering: 75 credits.
• AI extraction adds 5 credits.

Screenshot capture requires JavaScript rendering, so the non-rendered 1-credit path does not produce a screenshot. Auto-Mode charges for the configuration that succeeds, from the listed configurations, and supports a maximum-cost cap.

The screenshot product page listed Hobby at $19/month for 15,000 API credits and 25 concurrent requests; Freelance at $49 for 50,000 credits and 50 concurrent requests; Startup at $99 for 200,000 credits and 100 concurrent requests; Business at $249 for 600,000 credits and 200 concurrent requests; and Business+ at $599 for 1,600,000 credits and 400 concurrent requests. Prices exclude VAT. The page also advertises 1,000 free API credits without a card. These are vendor-published plan details, not a normalized cost comparison.

Browserless units

Browserless listed Free at $0/month with 1,000 units/month and 2 concurrent browsers; Prototyping at $25/month billed annually with 20,000 units; Starter at $140/month billed annually with 180,000 units; and Scale at $350/month billed annually with 500,000 units. The shown maximum concurrency was 2, 10, 40, and 100 respectively. Paid tiers list overage rates.

One unit is up to 30 seconds of browser connection time. Residential proxy traffic uses 6 units per MB, datacenter proxy traffic 2 units per MB, and a successful CAPTCHA solve 10 units. Enterprise pricing is custom. Annual billing and plan conditions affect those prices.

Estimate your real monthly cost

1. Count expected captures, separating viewport, full-page, and selector jobs if their rendering behavior differs.
2. For ScrapingBee, estimate credits per request for the JavaScript and proxy settings your screenshots require; include retries and any premium or stealth configuration.
3. For Browserless, estimate browser connection duration per capture, then include proxy traffic, CAPTCHA solve units when relevant, concurrency, and overages.
4. Measure a representative sample of your own pages and record output completeness, timeouts, duration, and billed usage. Keep those measurements specific to your pages and settings.
5. Compare against plan quotas and concurrency limits. Raw monthly plan prices alone do not show which service costs less for your workload.

6. Capture quality, blocking, and reliability

A screenshot is the state the browser could render at capture time. It can vary with viewport, responsive breakpoints, font and image loading, page scripts, consent dialogs, lazy loading, and target-site defenses. Set viewport dimensions before capture and use the relevant wait controls. For lazy-loaded content, scroll before the screenshot; Browserless documents scrollPage: true for triggering lazy loading.

Browserless calls out blank or white images, CAPTCHA pages, 403/access-denied pages, and missing or broken elements as possible signs of automation blocking. Its documentation points to the /unblock API and residential proxies as possible mitigations, without guaranteeing success. ScrapingBee exposes proxy settings, wait controls, and interaction scenarios. Neither source set provides an independent success-rate or fidelity benchmark.

For a reliable capture pipeline, record status codes and response headers, set a finite client timeout, retry only transient failures with a bounded policy, and distinguish a valid blocked-page screenshot from a transport failure. Avoid unbounded retries: they add delay and may increase metered usage. Where output completeness matters, verify that the expected image file is non-empty and decode it before storing or serving it.

7. Troubleshooting

Symptom	Likely cause	What to change
ScrapingBee returns an error instead of an image	Missing JavaScript rendering, invalid parameters, authentication, or an upstream request failure.	Set render_js=true, check the API key and parameter spelling, inspect the response body/status, and verify the target URL is reachable.
Only the visible viewport appears	Full-page capture was not enabled.	Set screenshot_full_page=true in ScrapingBee or fullPage in Browserless.
Screenshot is blank or shows an access-denied page	The target may block automation, or its content may not have rendered before capture.	Check the page in a normal browser, add a suitable wait, inspect proxy/unblock options, and treat those features as mitigations rather than guaranteed bypasses.
Images or sections are missing	Lazy loading, late image loads, or capture before the relevant element appears.	Scroll the page before capture, use image-wait support where available, or wait for a specific selector/state.
Wrong responsive layout	Viewport was not set to the intended dimensions before rendering.	Specify width and height explicitly and keep them consistent across captures.
Selector capture fails or is empty	The selector does not match, appears late, or identifies a zero-size element.	Validate the selector in the target page, wait for it to appear, and confirm the element has a visible bounding box.
Request times out	Slow scripts, long waits, a heavy full-page render, or a network problem.	Set a finite but adequate timeout, reduce unnecessary waits, capture a selector or viewport if sufficient, and retry transient failures sparingly.
Unexpected usage or cost	Rendering/proxy configuration, retries, browser duration, traffic, or concurrency differs from the estimate.	Inspect per-request usage, cap ScrapingBee Auto-Mode cost where used, and compare Browserless connection time and proxy units against plan limits.

8. Performance and operational choices

• Wait for a condition, not an arbitrary long delay. A selector or known readiness condition can avoid paying in latency for idle time, while a page-specific delay can help when the page has no reliable signal.
• Keep capture scope proportional. Viewport capture generally involves less page content than full-page capture; selector capture can avoid rendering a large image when only one component is needed.
• Choose output deliberately. PNG preserves lossless detail; JPEG or WebP may reduce transfer size where supported and appropriate. Compare visual requirements and downstream consumers.
• Bound concurrency and retries. Respect plan concurrency, set request timeouts, and use limited backoff for transient errors. A retry is another request or browser connection and can affect cost.
• Track duration and completeness together. A fast response that captures a loading shell is not a useful result. Log settings with each capture so a missing element can be traced to the viewport, waits, or proxy configuration.

For cost-sensitive jobs, cache only when the page’s freshness requirements allow it. Browserless and ScrapingBee pricing descriptions in this dossier do not establish equivalent screenshot caching behavior, so include any cache layer you build in your own cost and freshness design.

9. Or skip the browser setup

ScreenshotNeo returns a screenshot from one GET request. The [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) describes the available options, including full-page capture, element selectors, waits, custom headers, and PDF output.

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

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)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners, newsletter 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 not billed; response headers report the page verdict and billing outcome.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
• The free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up for ScreenshotNeo’s free 1,000 screenshots a month, with no card required.

10. FAQ

Can I send inline HTML to either service?

Browserless documents inline HTML input for its screenshot endpoint. The ScrapingBee workflow described here captures a URL through its HTML API.

Does a higher resolution guarantee a more accurate screenshot?

No. Device scale factor changes output pixel density; layout still depends on viewport dimensions, loaded assets, page state, and the capture timing.

Which one should I choose if I need a universal winner?

The available evidence does not support one. Run a controlled comparison on your own representative URLs and include completeness, latency, blocked results, and actual metered usage.

Sources

• ScrapingBee HTML API documentation and published pricing.
• Browserless Screenshot API, REST API overview, and published pricing.
• ScreenshotNeo documentation.