Best Website Screenshot APIs for Capturing Pages with Authentication

For an authenticated page you own or are authorized to access, first identify how the site establishes its session. If it accepts a request header or session cookie, an API can often capture the page after you obtain and pass a valid credential. If login requires interactive browser steps, choose a browser automation workflow that supports establishing and reusing that session. A screenshot endpoint that renders URLs does not necessarily sign in for you.

ScreenshotNeo is the first option to consider when your authorized capture can use headers or cookies: it supports custom headers, cookies, and Authorization, alongside its screenshot and PDF capture options. For credentials that must be acquired through a browser login, evaluate the browser-profile workflow separately and confirm its integration with the screenshot endpoint.

How to choose an authentication workflow

Choose based on the session mechanism, not just the word “screenshot” in a product description.

Workflow	How it works	Good fit when	What to verify
Authorization header	Your application obtains a token and sends it with the capture request.	The target accepts a bearer token or another authorization header.	Token scope and expiry; whether credentials reach only the intended origin and any needed subrequests.
Session cookie	Your application signs in through an approved mechanism, obtains a session cookie, then passes it to the capture service.	The site uses cookie-based sessions and you can securely acquire a valid cookie.	Cookie domain, path, expiry, SameSite behavior, and whether the capture browser receives the cookie for the intended host.
Saved authenticated browser profile	A browser workflow establishes a session and stores browser state for later reuse.	The site needs interactive login steps or a persistent browser session.	How the profile is saved, refreshed, isolated, and connected to the screenshot endpoint you plan to call.

Use these methods only for pages you own or are authorized to access. A site’s login controls and terms still apply. Do not try to bypass access controls, bot checks, or multi-factor requirements.

What the documented APIs support

The following comparison is based on the providers’ cited documentation, not independent testing. Confirm current behavior and pricing before building a production dependency.

Service	Documented authentication path	Important qualification
ScreenshotNeo	Custom Authorization, headers, and cookies; its API returns screenshots or PDFs and supports a broad set of capture controls.	Use a credential the target permits and can accept in a request. Its MCP server also exposes screenshot and page-info tools for AI clients.
ScreenshotOne	Custom authorization headers, other custom headers, or cookies. Its guide also discusses allowing its servers through a site firewall.	Obtaining cookies may require your own code to sign in. Its documentation recommends HTTPS because HTTP can expose keys, headers, and cookies in transit.
Browserless	A REST screenshot endpoint accepts a URL and Puppeteer-style options. Separately, Browserless documents saving logged-in browser state and reusing it across sessions.	The cited profile guide does not establish exactly how that saved state integrates with the one-shot screenshot endpoint. Verify the specific workflow before choosing it.
HTML/CSS to Image	The URL-to-image API accepts a short-lived session cookie or authorization token through its headers parameter.	Its documentation explicitly says the API does not automate an interactive login flow. Custom headers are normally sent to the requested origin; configure other origins and subrequests deliberately.

References: ScreenshotNeo documentation; ScreenshotOne authenticated pages, options, and getting started; Browserless screenshot API and session management; HTML/CSS to Image URL-to-image and headers reference.

Pass a header or cookie safely

The basic sequence is the same across providers: acquire an authorized, preferably short-lived credential; send it over HTTPS to the capture API; and limit its scope to the target site and the shortest practical lifetime. Keep secrets on a server you control. Do not put long-lived tokens or session cookies in client-side JavaScript, public image URLs, source control, or logs.

ScreenshotNeo: authorized request header

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/account \
  --data-urlencode 'headers={"Authorization":"Bearer YOUR_SHORT_LIVED_TOKEN"}' \
  -o account.webp

For supported options and parameter names, see the ScreenshotNeo API documentation. Supply the target’s required header format and keep both the ScreenshotNeo API key and target credential secret.

ScreenshotOne: authorization header or cookie

ScreenshotOne documents authorization and cookies among its capture options. Use its current options reference for the exact request syntax and encoding expected by your chosen endpoint; do not assume that every provider uses the same parameter names. The caller remains responsible for obtaining a valid cookie when the site requires a login.

HTML/CSS to Image: short-lived credentials

Its URL-to-image API documents passing a short-lived session cookie or authorization token in the headers parameter. Follow its headers reference for origin restrictions and for whether headers are sent on resource subrequests. Do not use this flow as a substitute for interactive login automation: the provider says its API does not automate that flow.

Browserless: screenshot endpoint and browser state

The REST screenshot API uses a POST request to /screenshot, a token query parameter, and Puppeteer-style options, with PNG, JPEG, or WebP output documented. Browserless separately documents saved browser state for authenticated sessions. Treat these as separate documented capabilities until you have confirmed how the desired profile is supplied to the screenshot call.

Or skip the browser setup

For a page that accepts a request credential, ScreenshotNeo can take the screenshot directly. This example uses its documented request pattern; adapt the target URL and add your authorized headers or cookies as required. See the API docs for 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,
)
r.raise_for_status()
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies page verdict and billing status in headers. Its MCP server lets AI agents use screenshot, page-info, and PDF tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for the free plan.

Credential handling checklist

• Use HTTPS for both capture API calls and any credential acquisition. ScreenshotOne specifically warns that HTTP can expose API keys, authorization headers, and cookies in transit.
• Prefer short-lived, narrowly scoped tokens over durable account passwords or broad session credentials.
• Constrain a credential to the intended hostname, route, and operation where the target supports it.
• Check whether custom headers are sent to the page origin only or also to third-party resources. HTML/CSS to Image documents origin behavior and explicit configuration for other origins and subrequests.
• Redact credentials from application logs, error reports, tracing, and saved request URLs.
• Refresh expired sessions through your normal authorized login flow; do not assume a screenshot provider refreshes them.
• Use a separate test account with minimum access when validating an integration.

Capture details that affect authenticated pages

Authentication only gets the browser through the gate. The page may still require the right viewport, wait condition, or resource behavior to produce the expected result. ScreenshotNeo documents full-page capture with lazy images loaded, element capture by CSS selector, dark mode, device presets and custom viewports, retina scale, custom CSS and JavaScript, click-before-capture, selector or delay or network-idle waits, request and resource blocking, timezone and geolocation, resizing, caching, async jobs, bulk capture, and PDFs with page settings. These options can address layout and timing differences after a session is accepted.

Do not block requests indiscriminately on a page that uses API calls to populate authenticated content. Likewise, a very short wait can capture the login shell before the app redirects or hydrates. Prefer a meaningful selector that appears only after the protected content loads, where supported, and validate that it cannot match the logged-out page.

Common failures and fixes

Symptom	Likely cause	What to do
Screenshot shows a login form	Credential missing, expired, malformed, or not valid for the target host/path.	Confirm the header or cookie in an authorized request to the same origin. Check expiry, domain, path, and the exact authorization scheme.
Works in your browser but not in capture	Your local browser has session state that the capture request did not include, or the site depends on an interactive flow.	Pass a permitted header/cookie explicitly, or use a browser automation workflow that can establish and reuse the profile. Confirm how that profile reaches the screenshot endpoint.
Protected content is blank or incomplete	Client-side data has not loaded, a required subrequest lacks credentials, or resource blocking interferes.	Wait for a protected-content selector or suitable load condition; inspect origin and subrequest header rules; remove blocking options that affect required APIs.
Redirect loop or unexpected redirect	Cookie scope, HTTPS assumptions, callback URL, or application redirect policy differs in the capture context.	Check the target’s redirect chain and cookie settings. Use the canonical HTTPS URL and the same allowed callback behavior as your normal client.
401 or 403 response	Credential lacks permission, is expired, or the target rejects the capture request under its own policy.	Verify access with the site owner and inspect the token’s scope. Do not try to evade an access denial; configure an approved integration.
Provider API rejects the request	Wrong endpoint, parameter name, encoding, method, or output setting.	Use that provider’s current API reference and examples. The APIs differ; a working parameter on one service may not be valid on another.
Credential unexpectedly reaches another host	Custom headers or cookies are applied to redirects or subresource requests more broadly than expected.	Review the provider’s origin controls, allow only necessary destinations, and use a short-lived token with limited scope.
Intermittent results	Session expiry, site-side rate limits, variable application load, or asynchronous rendering.	Refresh sessions through the approved flow, use bounded retries for transient failures, wait for page-specific readiness, and avoid retrying permanent authorization errors.

Performance, reliability, and cost

Capture time depends on the target page, authentication path, browser work, and readiness condition. Full-page captures and pages with large images or substantial client-side rendering generally require more browser work than a small viewport screenshot. No comparative performance benchmark was established in the research for these providers, so choose using a representative page and measure your own authorized workload.

For reliability, separate credential acquisition from capture. Track session age and expiry, distinguish authorization failures from transient timeouts, and retry only errors that can plausibly recover. If a provider offers saved browser state, plan for re-authentication and state isolation, and verify exactly how the profile is used. Test against both a valid session and an expired one so a login-page screenshot is not mistaken for successful capture.

Compare current quotas, rate limits, billing rules for unsuccessful renders, and the features your workflow actually needs. ScreenshotOne’s official pricing page showed 100 free screenshots per month when checked on 2026-10-03; that figure and its paid plans can change. ScreenshotNeo’s stated pricing is Free for 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, and Business $249 for 1,000,000; yearly billing gives two months free, and every feature is on every plan. Recheck provider pricing and terms before committing.

Frequently asked questions

Can a screenshot API bypass a login?

No. It can render a page when the request has authorized access. It should not be used to bypass the site’s access controls.

Can I send a username and password to a screenshot endpoint?

Prefer a short-lived token or session cookie obtained through an approved flow. Sending a password to a capture service expands where that secret is handled and is not necessary for APIs designed to accept request credentials.

Does a cookie passed to the API guarantee access?

No. It must be valid for the relevant host and path, unexpired, accepted by the target, and available to the page’s required requests.

Which option is best if login requires a one-time code?

Use an authorized browser workflow that can complete the site’s supported sign-in process and securely reuse state. Verify that the resulting profile is compatible with the capture endpoint.

Should I use this for pages I do not own?

Only if you have authorization from the site owner and the access method complies with the site’s policies.