Compare Website Screenshot APIs for Authenticated Pages and Cookie Banners
Compare screenshot APIs for authenticated pages and cookie banners, with working code, setup choices, failure fixes, and a practical provider checklist.
To capture an authenticated page, send the credentials the site expects: usually an authorization header or session cookie, or use a browser workflow to complete a login and obtain a session. Handle the cookie banner separately: banner blocking is not the same as authentication. Then inspect the image for the expected account content, a login screen, a banner, or an automation block. No provider documentation establishes that any service works with every site.
For an API that combines banner cleanup with explicit billing outcomes, ScreenshotNeo is the first alternative to consider: it removes known consent banners, newsletter popups, and chat widgets before capture, and says bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing. This guide also compares the documented approaches from ScreenshotOne, ApiFlash, Browserless, and Urlbox.
1. Choose the authentication method your target uses
Start with the target site’s actual authentication flow. A screenshot service does not necessarily log in as a user for you. For session-based sites, you may need to sign in through your own code, obtain a valid session cookie, and pass it to the capture API.
| Target authentication | Typical approach | Check before relying on it |
|---|---|---|
| Bearer token or API key | Pass the required authorization header. | Whether the service sends that header to the page request and how it scopes headers to subresources. |
| Browser session | Pass the session cookie with the required domain and path attributes. | Cookie expiry, domain, path, secure and same-site behavior, and whether the session is valid in the capture browser. |
| Interactive login form | Run a login workflow in a browser session, then capture with the authenticated session. | Redirects, MFA, CSRF protections, bot defenses, and the provider’s support for browser control. |
| Site you own or administer | Consider a site-controlled bypass secret or test-only authentication route where supported. | Keep bypasses restricted and avoid exposing them in public URLs or logs. |
Only automate pages you are permitted to access, and use an account with the minimum access needed. Do not put passwords, session cookies, or long-lived tokens in source control, public URLs, or client-side code.
2. Compare the documented provider approaches
The table reflects the reviewed provider documentation. It is not a neutral benchmark, and the documentation does not establish universal success, comparable prices, or success rates.
| Provider | Documented relevance | What to verify on your site |
|---|---|---|
| ScreenshotNeo | Website screenshot API and MCP server. It accepts one GET request for an image or PDF; it can remove known consent platforms, newsletter popups, and chat widgets, with each cleanup step configurable. It reports page verdict and billing headers. | Whether your authentication method and target site’s automation rules allow the expected page to render. Check the returned verdict and image. |
| ScreenshotOne | Its guide documents custom headers, cookies, and a firewall bypass for sites the customer controls. Its options document authorization, cookies, custom headers, and the block_cookie_banners option. |
Whether its header or cookie format works with your login, whether login code must run externally, and whether banner blocking works on the target. |
| ApiFlash | Its FAQ describes headers, cookies, a site-controlled secret bypass, and JavaScript login. It cautions that custom headers can affect external font requests. | Whether header scope affects fonts or other page resources; try cookies if appropriate. Confirm capture freshness and caching behavior for your use. |
| Browserless | Its screenshot API documents rendered images, full-page capture, and troubleshooting. Its platform overview describes screenshot APIs, browser-control sessions, and authenticated browser profiles. | Whether a simple screenshot endpoint is enough or you need a programmable browser session, and how login and banner handling must be implemented. |
| Urlbox | The reviewed POST API documentation covers POST requests and HTTP Basic authentication using the secret key as username. | The reviewed page does not establish the specific target-page authentication and banner features in this article; check the current documentation before treating it as a direct match. |
Compare providers on authentication methods, login workflow support, cookie attributes, banner controls, viewport and full-page behavior, automation-block outcomes, credential handling, cache freshness, current quotas and pricing, and target geography. The reviewed material does not support a universal winner across those dimensions.
3. A reliable workflow for authenticated captures
- Confirm access and permissions. Use a page and account you are authorized to automate. Check the website’s applicable rules.
- Identify the login mechanism. Determine whether the site accepts a header, session cookie, or requires browser interaction.
- Obtain credentials safely. If login is required, use your own login code or a supported authenticated browser session. Do not assume the capture API performs the login.
- Pass only what is needed. Use the provider’s documented header or cookie format. Include cookie attributes required by that API and ensure the cookie matches the target domain and path.
- Configure banner handling separately. For ScreenshotOne, the documented option is
block_cookie_banners. For ScreenshotNeo, consent cleanup is part of its capture features and individual cleanup steps can be turned off. Check the resulting image; neither description promises success on every site. - Inspect the result. Confirm that the intended account content appears and look for a login page, consent overlay, CAPTCHA, access-denied message, missing fonts, or missing elements.
- Repeat with one change at a time. If the result is wrong, change the auth method, banner setting, wait behavior, or browser workflow individually so the cause stays identifiable.
4. Runnable ScreenshotNeo examples
These examples use the documented endpoint and parameter names. Replace the API key and target URL. Keep the key on a trusted server. For parameters and response details, see the ScreenshotNeo API documentation.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
Python
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)
Node.js
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}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));
The sample target is public. For a protected page, use the authentication options documented for the provider and target; do not assume an undocumented ScreenshotNeo authentication parameter. If your target needs a custom login workflow, establish that flow and its supported session handoff before capture.
5. Cookie banners, login overlays, and page state
Authentication and consent are separate states. A valid session can still show a privacy banner, and removing a banner does not authenticate the request. A banner tool may also leave a site-specific modal or account prompt untouched.
- Test an authenticated URL with a fresh session and verify the expected account identity or page content.
- Test banner handling independently on the same page. Check whether the banner is removed, accepted, or simply absent because the session already stored consent.
- Watch for newsletter popups, chat widgets, and other overlays that can obscure content.
- When comparing providers, use the same URL, account, viewport, locale, and consent state. Save the resulting images and response status or verdict.
ScreenshotOne documents banner blocking for cookie banners, GDPR overlays, and privacy notices through block_cookie_banners. ScreenshotNeo supports removal of 60+ known consent platforms and newsletter popups and chat widgets; its cleanup steps can be switched off. These are documented features, not guarantees for every site’s markup.
6. Options to check for your use case
Capture controls can change whether the page is complete or comparable. Check the provider’s current parameter documentation before adding options; names and support differ.
| Need | Relevant controls to investigate |
|---|---|
| Page extent | Viewport versus full-page capture, element selection, and lazy-loaded image behavior. |
| Rendering state | Wait for a selector, fixed delay, or network idle; custom JavaScript or CSS when supported. |
| Visual consistency | Viewport or device preset, device scale, dark mode, timezone, geolocation, and locale where available. |
| Page access | Authorization headers, cookies, user agent, and site-specific login workflow. |
| Privacy and overlays | Cookie-banner handling, popup/widget removal, and ability to disable cleanup steps. |
| Output | PNG, JPEG, WebP, PDF, transparent background, resizing, or PDF page settings. |
| Freshness and throughput | Cache behavior and TTL, asynchronous jobs, bulk requests, and webhook support. |
ScreenshotNeo lists full-page capture with lazy images, CSS-selector element capture, dark mode, 12 device presets and arbitrary viewports, retina scale, PDF controls, custom CSS and JavaScript, click-before-capture, selector hiding, several wait modes, request and resource blocking, custom headers and cookies, user agent, timezone and geolocation, resizing, caching with a chosen TTL, signed public image links, asynchronous jobs with signed webhooks, bulk capture up to 100 URLs per call, a usage API, and an OpenAPI spec. Its parameter names used by other screenshot APIs also work, which can make migration easier. Confirm the exact current parameter syntax in the docs.
7. Troubleshooting common failures
| Symptom | Likely cause | What to try |
|---|---|---|
| Screenshot shows the login page | Credential missing, expired, scoped to another domain/path, or not accepted by the target. | Validate the session in a normal browser; refresh it; check cookie domain/path and authorization format; verify redirects and account permissions. |
| Screenshot shows CAPTCHA or access denied | The site is blocking or challenging automated traffic. | Check whether automation is permitted and whether the site offers an approved integration or controlled test path. Do not assume another screenshot endpoint will bypass the defense. |
| Blank image or missing content | Page load failure, timeout, blocked resources, delayed rendering, or automation defense. | Inspect the provider’s error or verdict information; test a longer or selector-based wait where supported; verify the page loads from the capture environment. |
| Banner remains visible | Banner implementation is not recognized, appears after initial render, or uses a custom overlay. | Wait for the overlay, check provider banner options, and consider a site-specific CSS or interaction workflow if supported. Verify the image rather than assuming the option succeeded. |
| Fonts differ or are missing | Custom headers may be applied to external font requests and cause them to fail. | ApiFlash flags this possibility. If compatible with the site’s auth design, try cookies instead of broad custom headers; otherwise narrow the header scope if the provider supports it. |
| Some account content is missing | Content loads after the initial page, requires scrolling, or is hidden behind another interaction. | Use a supported wait condition, full-page/lazy-load behavior, or browser interaction. Check for a missing-element or failed-request signal. |
| Capture differs between runs | Session expiry, dynamic content, cached output, changing viewport, or asynchronous page state. | Use a fresh valid session; set a consistent viewport and wait condition; check cache TTL and force freshness if supported. |
Browserless documents blank screenshots, CAPTCHA pages, access-denied pages, and missing elements as signs that a target may block automation. Treat these as diagnostic signals: a different wait time alone may not solve an access restriction.
8. Performance, reliability, and cost
- Performance: Authentication adds work if a browser must execute a login flow. Reusing a valid session can avoid repeating that flow, when the provider supports it and the session remains valid. Large full-page captures, slow resources, and long waits increase completion time.
- Reliability: Session expiry, MFA, CSRF tokens, redirects, geography, and anti-automation behavior can make captures intermittent. Validate image content, not only an HTTP success status. Keep a representative test page and compare captures after changes.
- Credential security: Store keys and session material in server-side secrets. Limit their lifetime and scope, redact them from logs, and avoid placing credentials in screenshot URLs that may be retained in history.
- Cost: Compare current plan limits, cache billing, failed-capture treatment, and costs for asynchronous or bulk workflows directly with each provider. The research dossier does not provide neutral comparable pricing. ScreenshotNeo states that only clean shots are billed; bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing state.
ScreenshotNeo pricing in the supplied product details is Free: 1,000 shots/month with no card; 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, and every feature is on every plan. Check the current plan page before budgeting.
9. Or skip the browser setup
ScreenshotNeo takes a screenshot with one GET request:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
See the API docs for options. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets Claude, Cursor, and other MCP clients use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000.
Create a free ScreenshotNeo account.
10. Frequently asked questions
Can a screenshot API log in to any website for me?
No. Some workflows pass existing credentials, and some browser platforms support programmable login sessions. The target’s login and automation rules determine what works.
Does accepting a cookie banner authenticate my session?
No. Consent state and login state are distinct. A capture can be authenticated and still show a banner, or have consent recorded without being logged in.
Should I use a cookie or an authorization header?
Use the method the target expects. Cookies can fit browser sessions; headers can fit token-based access. Test effects on fonts and other subresources when using custom headers.
Can I compare providers using a public page?
A public page can compare rendering and banner behavior, but it cannot establish whether a provider handles your protected page’s authentication flow. Test the actual target with a permitted account.
