Does Browshot Support Authenticated Pages and Login Cookies?

Yes. Browshot documents several ways to screenshot authenticated pages: pass an existing session cookie, automate a login form, submit POST data, or use HTTP Basic authentication credentials in the URL. The cookie and POST parameters are documented as paid-only, while the login guide says its dashboard automation is available for premium and private browsers. These are documented mechanisms, not a guarantee that every site’s login flow will work.

1. Choose an authentication method

Method	Use it when	Documented boundary
Existing session cookie	You already have a valid session cookie for the target site.	Paid screenshots; cookies are set for the requested URL. Separate multiple cookie pairs with semicolons. Browshot API documentation
Automated form login	The browser must enter credentials, submit a form, and continue through page interactions.	The login guide describes dashboard steps for premium and private browsers. Browshot login guide
POST data	The login endpoint accepts form-encoded data and direct submission fits the flow.	Paid screenshots; the docs give a form submission example. Custom requests guide
HTTP Basic authentication	The protected resource uses HTTP Basic authentication.	Browshot lists credentials in the URL as an approach. URLs may be recorded in logs or request records. Password-protected sites guide

2. Reuse an existing session cookie

Use this when you can obtain a valid session cookie through an authorized login. Pass the cookie with the screenshot request. Browshot documents semicolon-separated cookie pairs and says the cookie applies to the requested URL.

curl -G "https://api.browshot.com/api/v1/screenshot/create" \
  --data-urlencode "url=https://example.com/account" \
  --data-urlencode "cookie=session_id=YOUR_SESSION_VALUE" \
  --data-urlencode "key=YOUR_BROWSHOT_API_KEY"

Use the API’s documented endpoint and required parameters for your account; the example illustrates the cookie parameter. For multiple cookies, pass a value such as session_id=VALUE; preference=VALUE. Treat cookie values as credentials: keep them out of source control, shared logs, and public issue reports, and use only sessions you are authorized to access.

3. Automate the login form

If you do not already have a session cookie, Browshot’s login guide describes browser steps to type into username and password fields, click the submit control, wait for navigation, open a protected page, and capture it. The guide exposes these steps through Advanced options in the dashboard for premium and private browsers. The exact selectors and sequence depend on the target website.

1. Open the screenshot configuration in Browshot and select a supported premium or private browser.
2. In Advanced options, configure steps that fill the username and password fields and submit the form.
3. Wait for the login to complete, then navigate to the protected URL and capture it.
4. Check the resulting image to confirm the session persisted and the page reached the expected state.

For example, a site may show a consent prompt, redirect to a one-time-code page, or require a second click after password submission. Add the necessary browser interactions and waits if the documented basic sequence does not reach the target page. Browshot documents the mechanism, but does not promise compatibility with every login flow. See the login walkthrough.

4. Submit POST data

Browshot documents post_data for paid screenshots, including an example of submitting username and password form data to a login URL. This is suitable only when the endpoint accepts a direct form POST and that request establishes the session needed for the capture.

curl -G "https://api.browshot.com/api/v1/screenshot/create" \
  --data-urlencode "url=https://example.com/login" \
  --data-urlencode "post_data=username=YOUR_USERNAME&password=YOUR_PASSWORD" \
  --data-urlencode "key=YOUR_BROWSHOT_API_KEY"

Form field names, encoding, redirects, and subsequent navigation are site-specific. Some flows need a browser to execute JavaScript or interact with another page after submission; use the browser-step method in that case. Review the POST data documentation for the parameter format.

5. HTTP Basic authentication

For a site protected by HTTP Basic authentication, Browshot’s password-protected-sites guide lists credentials embedded in the target URL, in the form https://username:password@example.com/path. Because URLs can appear in logs and request records, avoid exposing real credentials in shared code or logs. Confirm that the target uses Basic authentication rather than a normal HTML login form.

6. Verify the capture and handle edge cases

• Cookie scope: a cookie must apply to the requested host and path, and must still be valid. A cookie for a different subdomain may not authenticate the target URL.
• Expired or rotated session: refresh the session cookie after signing in again. Sites can invalidate sessions or bind them to additional state.
• Redirects: confirm the capture reaches the protected destination after login instead of stopping at a sign-in page.
• Multi-factor authentication: the reviewed documentation does not promise support for every second-factor flow. A site may require additional interactions or may block automated access.
• JavaScript-dependent login: direct POST data may not be sufficient when the site relies on client-side code or a multi-step browser flow.
• Site-specific protections: bot checks, CAPTCHA challenges, or other access controls can prevent the browser from reaching the page.
• Authorized access: only submit credentials and reuse session cookies for accounts and pages you are permitted to access.

7. Common problems and fixes

Symptom	Likely cause	What to try
The screenshot shows a login page.	The cookie is invalid, out of scope, or expired, or the login steps did not complete.	Refresh the session; check the target host and cookie scope; add a wait after submission and verify the redirect.
POST data does not sign in.	The endpoint requires different field names, encoding, a CSRF value, or browser-side interaction.	Check the site’s form requirements. Use browser automation when a direct form POST is insufficient.
The browser stops at a challenge or second-factor page.	The site requires an additional authentication or verification step.	Determine whether the flow can be completed with supported browser steps. The documentation does not guarantee every such flow.
A cookie parameter is rejected or unavailable.	The screenshot request may not be using a paid configuration.	Check the API parameter requirements and paid-only restriction in the API reference.
Credentials appear in logs.	Credentials were embedded in a URL or recorded with request details.	Restrict access to logs, remove exposed secrets where possible, and rotate credentials if they were disclosed.

8. Performance, reliability, and cost

Authentication adds work before the actual capture: a browser may need to submit a form, wait for redirects, and load the protected page. Reusing a valid cookie can avoid repeating those login interactions, but it depends on session lifetime and cookie scope. A login flow may fail when the site changes its form, requires extra verification, or rejects automation.

Browshot’s reviewed documentation marks cookie and post_data as paid screenshot parameters and describes dashboard login automation for premium and private browsers. It does not provide current plan prices in the reviewed materials. Check the current API documentation and account options before choosing a method; no universal compatibility or completion-time guarantee is stated in those sources.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its one-call API can capture the protected URL when you provide the required authorization details supported by your target flow:

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

See the ScreenshotNeo API documentation for request options and authentication configuration. 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 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 for 1,000 screenshots a month, with no card.

10. FAQ

Can Browshot take screenshots behind a login?

Yes. Its documentation describes session cookies, browser-based form automation, POST data, and HTTP Basic authentication, subject to the method’s documented limits.

Can I pass a session cookie to Browshot?

Yes. The API documents a cookie parameter for paid screenshots. Separate multiple cookie pairs with semicolons.

Does Browshot support every login provider or two-factor flow?

The cited guides describe mechanisms, not universal support. A particular site may require additional browser interactions or verification.

Is login automation included for every Browshot browser?

The login guide says its dashboard automation steps are available for premium and private browsers. The API reference marks cookie and POST options as paid-only.

Sources

• Browshot API Documentation
• Log in to a website to take screenshots
• Webshots of password-protected sites
• Custom requests for your screenshots