Screenshot API vs Browserless for Website Captures
Compare ScreenshotAPI.net and Browserless for website captures, including code, options, pricing, and a practical pilot plan. See where ScreenshotNeo fits.
For a focused URL-to-image or PDF workflow, evaluate ScreenshotAPI.net, a managed screenshot-first service. For screenshots that are one step in wider browser automation, evaluate Browserless, whose REST API includes a screenshot endpoint. Neither vendor’s documentation establishes which produces more reliable captures on a particular site, so run a pilot against your own pages before choosing. If you want a direct screenshot API with consent-banner cleanup and usage-based billing only for clean captures, put ScreenshotNeo first on your shortlist.
This guide compares documented capabilities and pricing checked on October 3, 2026. Plan details can change; confirm current terms before purchase. Vendor-described capabilities below are not independent quality benchmarks.
1. The short answer: choose by workflow
| Need | Start by evaluating | Why |
|---|---|---|
| Screenshot or PDF jobs, scheduled captures, and capture-specific controls | ScreenshotAPI.net | It is positioned as a managed screenshot-focused service and documents scheduled screenshots, customer-selected object storage, PDF, scrolling video, and ad or cookie blocking. |
| Screenshot as one action within broader browser automation | Browserless | Its screenshot endpoint is part of a broader browser API offering. REST calls are stateless, single-action requests. |
| A direct screenshot API with clean-shot handling, a usage verdict, and an MCP server for AI agents | ScreenshotNeo | Its API returns a screenshot or PDF from one GET request, identifies page verdict and billing in response headers, and offers MCP tools. |
There is no evidence here for a universal winner on capture fidelity, latency, or reliability. Test representative pages—including your slow, dynamic, protected, and authenticated cases—under comparable settings.
2. What each service documents
ScreenshotAPI.net
ScreenshotAPI.net describes managed Chromium capture with viewport and full-page screenshots, PNG/JPEG/WebP, PDF output, scheduled screenshots stored in a customer-selected S3, Google Cloud, or Wasabi bucket, scrolling video, text and HTML extraction, custom viewport and selector controls, and ad and cookie-banner blocking. It lists use cases such as visual regression, monitoring, archiving, social previews, and scheduled page capture. These are provider descriptions, not independent verification.
Its product page also advertises figures including “10,000+ developers,” “75+” API parameters, “20,000+” ad-blocking rules, and a “99.9%” uptime SLA. Treat these as ScreenshotAPI.net’s own claims; they were not independently verified in the research.
Browserless
Browserless documents a REST /screenshot endpoint that accepts a URL or inline HTML and supports PNG, JPEG, and WebP. Its request examples use Puppeteer-style options and show viewport, full-page, selector, clip-region, device-scale, wait-condition, and injected script or style controls. The documentation also describes scrolling to trigger lazy-loaded content.
Browserless characterizes REST endpoints as single-action and stateless: a request launches a browser, performs the action, then closes the session. REST does not provide persistent session state or real-time interaction. Its documentation points to other Browserless products for persistent or interactive workflows. It documents /unblock and BrowserQL options for advanced bot protections, but that does not guarantee any protected site will render.
How to interpret the comparison
Both providers document full-page capture. That says what their products offer, not how completely either captures your pages. Dynamic content, cookie state, anti-bot responses, lazy loading, and site-specific scripts can change the result. Compare outputs on the same URLs and inspect the actual files.
3. Pricing and usage models
The displayed prices below were checked on October 3, 2026. They are volatile, and billing units are not directly comparable.
| Service | Displayed plan examples | Usage model and caveats |
|---|---|---|
| ScreenshotAPI.net | Essential: $9/month for 1,000 screenshots; Startup: $29/month for 10,000; Business: $175/month for 100,000. A free trial page stated 100 screenshots. | Displayed request limits were 20, 40, and 80 requests per minute by tier. Options such as scrolling screenshots and custom storage vary. A limited-time first-month promotion appeared during research; do not assume it remains available. |
| Browserless | Prototyping: $25/month; Starter: $140/month; Scale: $350/month, each marked billed annually. Displayed monthly units: 20k, 180k, and 500k. | A unit is up to 30 seconds of browser time per browser connection. Longer sessions use more units, and reconnects count as new connections. Session maximums, concurrency, persisted-session durations, and overage rates differ by tier. |
| 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. | Free has no card requirement. Yearly billing gives two months free. Every feature is on every plan. Only clean shots are billed; bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the verdict and billing indicated in response headers. |
Do not divide a Browserless plan price by a screenshot count unless you first measure browser time, reconnects, concurrency, retries, and the features you use. Likewise, compare ScreenshotAPI.net’s request limits and included options against your capture cadence. A representative pilot should track total successful output, elapsed time, retries, and usage billed under each provider’s rules.
4. Run a fair pilot before committing
- Build a representative URL set. Include static pages, pages with long-loading images, client-rendered content, pages with consent banners, authenticated pages if relevant, and known bot-protected pages.
- Normalize the request. Use the same viewport, device scale, full-page or viewport mode, output format, and readiness condition where both services allow it. Record service-specific settings that cannot be matched.
- Save and inspect outputs. Check that expected sections are present, text is not clipped, images have loaded, and overlays did not obscure the page. For PDF, inspect page breaks and dimensions.
- Record operations data. Track response status, elapsed time, retries, missing or blocked content, usage consumed, and billed units or shots. Include concurrency representative of production.
- Test failure behavior. Use pages that time out, redirect, return errors, or show bot checks. Confirm how the API reports the result and what the pricing model counts.
- Confirm governance requirements. Check current vendor terms for storage destination, log retention, data handling, deployment model, support, and procurement or security constraints.
This pilot answers which service works for your actual URLs. Vendor feature lists alone cannot establish capture quality or reliability for your workload.
5. Browserless screenshot request: shape and options
Browserless’s official REST documentation uses a POST request to /screenshot, with the API token in the query string. Its examples accept a URL or inline HTML and Puppeteer-style screenshot options. The exact request body and supported option values should be taken from the current endpoint documentation; use the following as a runnable request skeleton and add the documented options you need.
curl -X POST 'https://production-sfo.browserless.io/screenshot?token=YOUR_API_TOKEN' \
-H 'Content-Type: application/json' \
--data '{"url":"https://example.com","options":{"fullPage":true,"type":"png"}}' \
--output page.png
Use the Browserless documentation for the current host and exact payload fields for your account and endpoint. In particular, verify the spelling and accepted values for screenshot type, selector, clip, viewport, device scale, and wait behavior before relying on them.
Input and capture controls
- URL or HTML: choose a URL for ordinary web capture; use inline HTML where the documented API supports it and your task is to render supplied markup.
- Viewport or full page: viewport capture is appropriate for a visible screen region; full-page capture aims to include the document’s full height.
- Selector or clip region: use these when you need a specific element or rectangle rather than the whole page, if supported by the chosen endpoint option.
- Image format: the endpoint documents PNG, JPEG, and WebP. Choose based on downstream compatibility and size needs, then verify output content type and file.
- Wait conditions: page readiness varies. Use the endpoint’s documented wait option, and allow for site-specific client rendering rather than assuming navigation completion means all content is ready.
- Lazy-loaded content: Browserless documents scrolling to trigger lazy loading. Infinite-scroll pages may never have a natural end; define a bounded scroll strategy and validate the captured extent.
- Script and style injection: examples show custom scripts and styles. Keep changes scoped to the capture, and ensure injected scripts do not expose credentials or alter production data.
State and protected pages
A REST screenshot action does not preserve a browser session for a later request. If capture depends on login steps, state accumulated across requests, or live interaction, investigate Browserless’s persistent or interactive offerings rather than assuming REST will retain cookies. The documented /unblock and BrowserQL options may be relevant to advanced bot protections, but cannot promise access to every site.
6. Or skip the browser setup
ScreenshotNeo turns a URL into an image or PDF with one API request. See the ScreenshotNeo API documentation for request options. The same parameter names other screenshot APIs use also work, which can ease a switch.
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 are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot. Each step can be turned off.
- Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are never billed. The response includes
X-Page-VerdictandX-Billedheaders. - An MCP server gives AI agents, including Claude, Cursor, and any MCP client, the tools
take_screenshot,get_page_info, andcapture_pdf. - 1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000.
Sign up for ScreenshotNeo’s free 1,000 screenshots a month, with no card required.
7. ScreenshotAPI.net and Browserless troubleshooting
| Symptom | Likely cause | What to check or change |
|---|---|---|
| Screenshot is blank or mostly empty | Navigation completed before client-rendered content appeared, a failed load, or a bot check. | Inspect the page in a normal browser, use a documented wait condition, and check response status and output. Test the same URL with a bounded additional wait. |
| Lower page or images are missing | Lazy loading or infinite scrolling did not trigger. | Use documented scrolling behavior, wait after scrolls, and set a finite scroll limit for pages without a natural end. Compare full-page output against the visible page. |
| Consent overlay covers the page | The site requires a consent interaction or the provider’s blocking behavior differs. | Check the provider’s documented cookie/banner controls. For Browserless, use the documented interaction or injected script only where permitted and appropriate; validate that the resulting page matches your intended capture. |
| Protected page returns a challenge or error | Bot protection, authentication, or access policy blocked the request. | Do not assume a screenshot endpoint bypasses protection. Confirm authorization and provider options; Browserless documents /unblock and BrowserQL for some workflows, without a success guarantee. |
| Screenshot is clipped or oddly sized | Viewport, full-page, selector, or clip settings do not match the target layout. | Set explicit dimensions and device scale, remove conflicting crop settings, and verify whether full-page capture or a selector was requested. |
| Request fails at higher volume | Rate limit, concurrency limit, plan session limit, or long browser sessions. | Check current tier limits and response errors; throttle, bound waits, and account for Browserless connection duration and reconnects or ScreenshotAPI.net’s displayed request-per-minute tier limit. |
| Usage is higher than expected | Retries, long sessions, reconnects, or a mismatch between billing units and jobs. | Log each request and provider usage. For Browserless, measure browser time and reconnect count; for ScreenshotAPI.net, count requests and confirm tier options and limits. |
8. Performance, reliability, and cost controls
- Bound waiting. Extra waiting improves the chance that delayed content appears but increases elapsed browser time and timeout risk. Tune waits on representative pages.
- Control full-page work. Very long pages and lazy images can require more loading and processing. Use viewport capture when the whole document is unnecessary; use bounded scrolling for endless feeds.
- Choose concurrency from observed behavior. Stay within the current request and concurrency limits, and increase load gradually while monitoring errors and tail latency.
- Make retries selective. Retry transient network or service errors with a limit and backoff. Avoid retrying permanent access denial or a site’s bot challenge in a tight loop.
- Cache when pages need not be fresh every time. Check each product’s current caching controls and freshness behavior. Do not assume repeated requests share output or billing treatment.
- Secure tokens and page data. Keep API credentials out of source control and public client code. Consider that URLs, headers, cookies, and captured pages may contain sensitive data; confirm provider retention and handling terms for your use.
- Compare total workflow cost. Include plan minimums, annual commitments, overages, browser duration, retries, storage, and operational work. Screenshot counts alone do not normalize Browserless’s browser-time units.
No independent head-to-head reliability or quality benchmark was established for this comparison. Treat reliability as a measured property of your URL set and deployment conditions.
9. FAQ
Which API is easier for full-page screenshots?
Both document full-page capture. Ease depends on the request options and page behavior you need; test with representative long and lazy-loaded pages.
Can I use Browserless for screenshots without managing a browser?
Yes. Its REST screenshot endpoint is a managed browser action. It is stateless, so it does not preserve a session for later REST calls.
Which one handles dynamic or lazy-loaded pages better?
The documentation alone does not settle that. Compare both on the actual pages, matching wait settings and checking that lazy content appears in the output.
Does Browserless REST keep me logged in between screenshots?
No persistent session is provided through the stateless REST endpoints described in its documentation. Investigate other Browserless products if a persistent or interactive workflow is required.
Can I compare their prices per screenshot?
Only after measuring your workload. ScreenshotAPI.net lists screenshot tiers; Browserless bills in browser-time units with duration, reconnect, concurrency, and overage factors.
