Can BrowserCat Capture Pages Behind a Login?

Short answer: BrowserCat supports cloud browser automation with Playwright and screenshots, so capturing a page after an authorized login appears technically possible as a browser-automation workflow. However, BrowserCat’s public documentation reviewed for this article does not provide a dedicated recipe for logging in to a third-party site, importing cookies, or reusing saved sessions. Test the exact login flow and inspect the screenshot before relying on it.

BrowserCat’s API key authenticates your client connection to BrowserCat. It does not log you in to the website you want to capture. The remote browser does not automatically inherit the cookies or login state from your local browser.

What BrowserCat’s documentation confirms

BrowserCat recommends Playwright as a starting point and supports other CDP clients. Its Quick Start demonstrates navigating to a page, waiting for it to load, taking a screenshot, and connecting to BrowserCat’s cloud browser endpoint. The configuration documentation describes API-key authentication for that service connection and documents browser selection and proxy options through a BrowserCat-Opts header or supported query parameters.

The reviewed pages do not explicitly show third-party login form submission, cookie import, or saved-session reuse. Treat those as implementation questions to verify for your target site, rather than as documented BrowserCat guarantees. BrowserCat Quick Start · BrowserCat Browser Configuration.

Capture a page after an authorized login

The general approach is to connect to BrowserCat’s remote browser, use Playwright to perform the authorized login flow, wait until the protected page is ready, and save a screenshot. The login steps below are site-specific: use the site’s intended authentication process and handle any additional verification it requires.

1. Set up the client

Follow BrowserCat’s current Quick Start for the supported client setup and install Playwright as directed there. Keep your BrowserCat API key in an environment variable or secret manager; do not hard-code or commit it. Use the documented secure WSS endpoint for the connection.

export BROWSERCAT_API_KEY="your_browsercat_api_key"

The connection format and authentication options should match BrowserCat’s current Quick Start and configuration documentation. The example below shows the Playwright workflow; adapt the connection call to the exact client setup BrowserCat documents for your account.

2. Navigate, log in, and capture

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(
  `wss://api.browsercat.com/connect?apiKey=${encodeURIComponent(process.env.BROWSERCAT_API_KEY)}`
);

try {
  const context = await browser.newContext();
  const page = await context.newPage();

  await page.goto('https://example.com/login', { waitUntil: 'domcontentloaded' });

  // Replace these selectors and values with the site's authorized login flow.
  await page.getByLabel('Email').fill(process.env.SITE_USERNAME);
  await page.getByLabel('Password').fill(process.env.SITE_PASSWORD);
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Prefer a stable, page-specific signal that proves login succeeded.
  await page.getByRole('heading', { name: 'Account overview' }).waitFor({ timeout: 30000 });
  await page.goto('https://example.com/account/report', { waitUntil: 'domcontentloaded' });
  await page.locator('[data-report-ready="true"]').waitFor({ timeout: 30000 });

  await page.screenshot({ path: 'protected-page.png', fullPage: true });
  await context.close();
} finally {
  await browser.close();
}

Use selectors and readiness conditions that match the actual site. The example’s login URL, fields, button, heading, and report-ready attribute are placeholders, not BrowserCat-provided selectors. If your BrowserCat account’s documented connection syntax differs, use that syntax while keeping the browser actions the same.

3. Validate the result

1. Open the saved image and confirm it shows the expected protected content.
2. Check that the page did not redirect back to the login screen or land on an error, challenge, or incomplete loading state.
3. Repeat the flow under the conditions you will use in production, including any required second-factor or account verification steps.
4. Only rely on a saved session if the specific persistence and lifetime behavior you need is documented and verified for your setup.

Login state, cookies, and persistence

A newly created remote browser context generally starts without your local browser’s site cookies. The workflow must authenticate within that browser or provide an authorized session through a mechanism supported by the site and your BrowserCat setup. The reviewed BrowserCat pages do not establish a documented cookie-import or persistent-login feature.

If the capture involves multiple pages in one run, keep them in the same browser context so the session state created during login can be used by later navigations in that context. Whether a session can be reused in a later browser connection is a separate question; verify the supported mechanism and lifetime rather than assuming persistence. Never use this workflow to bypass access controls or capture content you are not authorized to access.

Options and configuration to consider

• Browser client: BrowserCat recommends Playwright as a starting point and says it supports other CDP clients. Use a client that can perform the target site’s required browser interactions.
• Browser selection and proxy: BrowserCat documents configuration for these through a BrowserCat-Opts header and a subset of query parameters. Consult its configuration page for accepted values and syntax.
• Page readiness: Wait for a meaningful post-login element or state. A generic load event does not prove authentication succeeded or that protected content finished rendering.
• Credentials: Keep both BrowserCat credentials and destination-site credentials out of source control and logs. BrowserCat recommends HTTPS/WSS to protect private keys in transit.
• Session mechanism: The reviewed docs do not specify cookie import or saved-session reuse. Do not assume either is available; check current documentation for the precise workflow you need.

Common problems and fixes

Symptom	Likely cause	What to check
The screenshot shows the login page	The login did not complete, the session was not retained in the context, or the protected URL redirected.	Wait for a post-login signal, inspect the final URL, and keep the capture in the same context used for login.
The API key is rejected or the browser connection fails	The BrowserCat client connection is not authenticated or its endpoint/configuration is incorrect.	Compare the connection setup with BrowserCat’s Quick Start and configuration docs. Keep the key private and use WSS.
The login button is not found	The page has not rendered the form yet, or the selector does not match the site.	Wait for the actual form control and use a locator appropriate to the page. Check whether the login page differs by account or region.
The login appears successful, but content is missing	The page may need additional client-side rendering, navigation, or a site-specific readiness condition.	Wait for a stable element unique to the protected content and inspect the screenshot and final URL.
The flow pauses for verification	The site may require an additional interactive or account-specific verification step.	Use the site’s authorized verification flow if the automation setup supports it. Verify feasibility for this site instead of assuming every login can be automated.
A later run is logged out	The workflow may start a fresh context or the site session may have expired.	Authenticate again for that run unless a supported, verified persistence mechanism meets your requirements.

Performance, reliability, and cost considerations

Authenticated capture adds browser actions before the screenshot: opening the login page, completing the flow, waiting for the protected content, and capturing it. Use the narrowest reliable readiness condition rather than an arbitrary long sleep. Full-page screenshots can take longer and produce larger files than a viewport capture, so capture only the area you need when a full page is unnecessary.

Reliability depends on the target site’s actual login flow, session rules, page rendering, and any account-specific verification. The reviewed BrowserCat material does not provide a guarantee that every protected site or authentication method will work. Confirm the result visually and treat a login page or error page as a failed capture for your own workflow.

The research reviewed for this article does not establish BrowserCat pricing or per-capture costs, so check its current pricing information directly before estimating spend. For any service that processes login credentials or session state, consider which secrets are transmitted and stored, who can access them, and how long they need to remain valid.

Or skip the browser setup

If the page is publicly accessible, ScreenshotNeo offers a one-call website screenshot API. It is not a substitute for logging in to a private site: use it only where the target URL can be captured without authenticated access.

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 ScreenshotNeo API documentation for options. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000.

Sign up for ScreenshotNeo’s free plan and get 1,000 screenshots a month with no card.

FAQ

Does a BrowserCat API key log me in to the website?

No. It authenticates the client connection to BrowserCat; destination-site authentication is a separate step.

Can I use my normal browser’s existing login?

Do not assume so. A cloud browser session does not automatically inherit your local browser’s login. Authenticate in the remote workflow or use a session method that is explicitly supported and verified.

Does BrowserCat document saved cookies for authenticated screenshots?

The official pages reviewed here do not provide a cookie-import or saved-session recipe. Check the current BrowserCat documentation for changes before building around session reuse.

How can I tell whether the capture is authenticated?

Wait for a page element that only appears after login, inspect the final URL, and open the screenshot to confirm it contains the expected protected content.