Best Website Screenshot API for Capturing Pages Behind a Login

For a login-protected page, choose a hosted screenshot API when your application can provide a valid session cookie, token, or HTTP Basic Auth credentials. Choose Playwright when the browser must submit a login form, follow redirects, or perform other steps before capture. Among the hosted APIs covered here, ScreenshotNeo is the first alternative to try: it accepts custom cookies and headers, removes common consent banners and popups before capture, and bills only clean screenshots.

A screenshot API that accepts authentication data does not necessarily log in to the site for you. Your system still needs to obtain, refresh, and protect the credentials. Confirm that the returned image shows the expected authenticated page; a successful image response can still contain a login screen.

1. Identify how the page authenticates

“Behind a login” can mean several different things. Identify the mechanism before choosing a tool:

Authentication method	What the capture needs	Typical fit
Session cookie	A current cookie from an authenticated browser session	A hosted API that can set cookies for the target request
Bearer or custom token header	An authorization header accepted by the site	A hosted API that can send custom headers
HTTP Basic Authentication	The account credentials in the HTTP authentication exchange	A service that explicitly documents Basic Auth support
Interactive login	Browser actions such as opening a login page, entering credentials, submitting a form, or handling redirects	Playwright or another browser automation workflow

Cookies and tokens are usually temporary. A capture can fail after expiry, revocation, account changes, or a site-side session rotation. If login requires MFA, CAPTCHA, or other interactive checks, the reviewed documentation does not establish that a hosted screenshot endpoint handles those steps for you.

2. Compare the documented options

Tool	Documented authentication	Best fit	Boundary to keep in mind
ScreenshotNeo	Custom headers and cookies	One-call captures when your application already has valid auth data; also useful when clean captures and per-response page verdicts matter	Providing cookies or headers is not the same as completing an interactive login. Check the docs for the exact request parameters and supported behavior.
Cloudflare Browser Run	Session cookies, HTTP Basic Auth, and a custom Authorization header	A hosted screenshot request with an existing credential or cookie	The documented one-shot endpoint establishes credential injection, not arbitrary multi-step login interaction.
ScreenshotOne	Custom authentication headers and session cookies	A hosted capture when you can supply valid authentication data	Its guide notes that obtaining the site’s cookies may require separate code.
Capture API	HTTP Basic Auth and custom user-agent configuration	A protected page using Basic Auth or requiring a configured user agent	The reviewed authentication page does not substantiate general session-cookie injection or form-based login.
Playwright	Browser-driven login and reusable browser storage state	A flow that needs form submissions, redirects, or custom browser actions	You operate the browser automation and must protect stored authentication state. Session storage requires separate handling in the documented workflow.

This comparison reflects documented capabilities, not a measured provider ranking for speed, reliability, or success across arbitrary sites. Cloudflare Browser Run and ScreenshotOne are hosted candidates when you already have valid session data; Playwright is the clearest documented fit here when the browser must perform login steps.

3. Use a hosted API when you already have authentication state

For a stable cookie or token, the workflow is: obtain credentials in your own authorized login flow, send them with a screenshot request, and validate that the capture reached the expected page. ScreenshotNeo provides an HTTP GET endpoint for screenshot capture. The examples below use a public URL only; add the target site’s documented cookie or authorization parameters from the ScreenshotNeo API documentation for your integration.

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 image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

These examples demonstrate the base request and save the returned image. For an authenticated target, consult the API documentation for the precise cookie and header parameters; do not guess parameter names or put secret values in a URL that may be logged. Apply the same principle to Cloudflare Browser Run and ScreenshotOne: follow each provider’s documented request format for the chosen authentication method.

cURL with Cloudflare Browser Run

Cloudflare’s documentation covers session cookies, Basic Auth, and a custom Authorization header for its screenshot endpoint. The endpoint and parameter syntax are specific to that service, so use its official API reference rather than copying another provider’s request shape. Provide only a credential valid for the target host and an account you are authorized to access.

Python or Node.js with another hosted provider

The HTTP client pattern is the same: make the provider’s documented request, include the target URL and supported authentication data, check the HTTP status, and save the response bytes. The exact URL, parameter names, response format, and cookie serialization differ by provider. Use the official provider documentation for those values rather than treating the ScreenshotNeo example as interchangeable syntax.

4. Use Playwright when the browser must log in

Use browser automation when the site requires a login form or other browser-side actions before the capture. This runnable Node.js example uses Playwright to open a login page, submit credentials from environment variables, save browser state, then open a protected page and take a screenshot. Replace the selectors and URLs with the authorized test site’s actual values.

import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const context = await browser.newContext();
const page = await context.newPage();

try {
  await page.goto(process.env.LOGIN_URL, { waitUntil: 'domcontentloaded' });
  await page.locator('[name="email"]').fill(process.env.TEST_USERNAME);
  await page.locator('[name="password"]').fill(process.env.TEST_PASSWORD);
  await page.locator('button[type="submit"]').click();
  await page.waitForURL(process.env.AUTHENTICATED_URL_PATTERN);

  await context.storageState({ path: 'auth-state.json' });
  await page.goto(process.env.PROTECTED_URL, { waitUntil: 'domcontentloaded' });
  await page.locator('[data-testid="account-dashboard"]').waitFor();
  await page.screenshot({ path: 'protected-page.png', fullPage: true });
} finally {
  await browser.close();
}

Set LOGIN_URL, TEST_USERNAME, TEST_PASSWORD, AUTHENTICATED_URL_PATTERN, and PROTECTED_URL in the process environment. Use selectors and a post-login URL pattern that uniquely identify successful authentication for the site. The dashboard selector check helps catch a screenshot of the login form.

To reuse saved state in a later run, create the context with the storage-state file:

const context = await browser.newContext({ storageState: 'auth-state.json' });

Playwright’s storage state can contain cookies and headers capable of impersonating the account. Do not commit it to source control. Its documented storage-state workflow does not automatically persist session storage, so sites relying on session storage need separate handling.

5. Validate the result and protect credentials

1. Use an account and target page you are authorized to capture. Prefer a least-privilege test account.
2. Check the final URL after authentication, especially when redirects are involved.
3. Wait for a page-specific element that appears only after login, then verify it in the screenshot or browser automation.
4. Distinguish an image response from a correct capture: a login page, access-denied page, or blank state can still produce an image.
5. Keep API keys, passwords, cookies, and bearer tokens out of source control, client-side code, and logs. Send credentials using the provider’s documented secure mechanism.
6. Review the screenshot provider’s handling and retention terms before sending sensitive page content. Rotate or revoke an exposed session.

Cookies and stored browser state are account access credentials. Treat a saved storage-state file with the same care as a password, restrict access, and remove it when it is no longer needed.

6. Reliability, performance, and cost

There is no independent benchmark in the research for provider speed, uptime, regional availability, or success across login-protected sites. Test the actual target and authentication flow. Hosted APIs reduce the browser infrastructure you operate for straightforward credential injection. Playwright gives you direct control over browser steps, while making your service responsible for browser execution, state handling, and retries.

• Credential freshness: sessions expire and tokens rotate. Refresh auth state through the site’s supported login or authorization flow rather than retrying an expired credential indefinitely.
• Wait strategy: wait for a known authenticated-page selector or a bounded delay where needed. A fixed long delay wastes time; an early capture can miss data loaded after navigation.
• Retries: retry transient navigation or network failures with a limit and backoff. Do not repeatedly retry a login rejection or expired credential as if it were a transient error.
• Concurrency: keep capture concurrency within the provider’s documented limits and the target site’s acceptable request rate. The sources here do not establish universal rate limits.
• Costs: hosted APIs have plan or usage costs; self-hosted browser automation consumes compute and operational time. Compare current provider pricing and included usage before deployment. No cross-provider cost-per-success comparison is established here.

As of the vendor information retrieved on October 3, 2026, ScreenshotOne listed 100 free screenshots per month without a card, then plans of $17 for 2,000 credits, $79 for 10,000, and $259 for 50,000, excluding VAT. The vendor states that one output consumes one credit when that output type is available on the plan. Recheck the provider’s pricing page before purchase because prices and plan terms can change.

7. Troubleshooting

Symptom	Likely cause	Fix
The image shows the login screen	The cookie or token was absent, malformed, expired, scoped to another host, or rejected	Obtain fresh auth state; confirm cookie domain/path and header format; validate the final URL and a protected-page selector.
The response is an access-denied or bot-check page	The target denied the request or presented an additional challenge	Confirm access is authorized and the account works in a normal browser. The reviewed sources do not establish that a provider can bypass automation defenses.
Login succeeds but the capture is incomplete	Client-rendered content or data requests have not finished	Wait for a page-specific element or the site’s documented ready condition before taking the screenshot.
Playwright waits forever for the post-login URL	The URL pattern is wrong, a redirect is pending, or the site requires another login step	Inspect the resulting URL and page state; use a bounded timeout and an authenticated element check that matches the site.
Saved Playwright state works once, then fails	The session expired, was revoked, or depends on state not included in the saved file	Re-authenticate and save fresh state. Handle session storage separately when the site uses it.
Cookie works in a browser but not through the API	The cookie may have been copied incompletely or the provider request does not match its documented cookie format	Capture the current cookie value from an authorized session and follow the selected provider’s exact serialization instructions.
Credential appears in logs or source control	Secrets were embedded in code, URLs, or stored state files	Revoke or rotate the exposed credential, remove it from history where appropriate, and move secrets to protected configuration.

8. Or skip the browser setup

ScreenshotNeo takes a screenshot with one GET request. See the ScreenshotNeo API documentation for authentication parameters and the other capture options.

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

For a login-protected target, supply its valid cookie or header using the documented parameter. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up free and get 1,000 screenshots a month with no card.

FAQ

Does a screenshot API log in to a site for me?

Not necessarily. Cookie and header support usually means you provide already-valid authentication data. Check whether the specific provider documents interactive login automation before relying on it to submit a form.

Can I capture pages that require MFA or CAPTCHA?

The sources covered here do not establish that the hosted APIs handle arbitrary MFA or CAPTCHA flows. If your authorized workflow needs browser interaction, use a browser automation approach and verify that the site’s policies and login flow support it.

Which option should I choose for recurring captures?

Use a hosted API if your application can refresh and provide valid auth state and the capture is otherwise straightforward. Use Playwright when each run must perform browser actions or establish state through a custom login flow.

Is there a proven fastest or most reliable provider?

No independent comparison in the research establishes a universal leader for speed or reliability on authenticated pages. Validate providers against your own authorized target and expected page state.