How to Screenshot a Website Behind an Indian Login Page with Browserless

To screenshot a page that requires an Indian website login, first sign in through the site’s normal authorized flow in a Browserless browser session, save the authenticated browser state as a profile, then pass that profile to Browserless’s screenshot endpoint. The profile can restore cookies, localStorage, and IndexedDB before the protected page renders. This works only if the site’s login flow and access rules allow it; the target site is unspecified, so compatibility with its OTP, identity-provider, CAPTCHA, or device checks cannot be assumed.

Use the method only for accounts and pages you are authorized to access. Do not try to bypass a site’s access controls or challenges.

How the workflow works

1. Open a Browserless Chromium session using a CDP-capable client such as Puppeteer or Playwright.
2. Complete the site’s ordinary login flow. If login uses a third-party identity provider, wait for the final redirect back to the application.
3. Save the authenticated state as a Browserless profile after the protected page is accessible.
4. Make a POST request to /screenshot, supplying the target URL, API token, and saved profile.
5. Check that the screenshot shows the intended signed-in page, rather than a login page or intermediate challenge.

Browserless documents that it restores profile state before rendering and lists /screenshot as a profile-enabled endpoint. The screenshot endpoint is a separate HTTP request; use a browser session for the interactive login and profile setup, then use the REST endpoint for repeat captures. See the Authenticated Profiles and Screenshot API documentation.

Save an authenticated Browserless profile

Connect to Browserless with a CDP-capable client, sign in normally, and save the profile using Browserless’s authenticated-profile mechanism. Profile creation is performed in the browser session; the exact connection URL and profile-saving calls depend on your Browserless account and client setup. Follow the current profile guide for those steps rather than copying an invented endpoint or token format.

Before saving, wait for the whole login flow to finish. A successful sign-in may involve a redirect through an identity provider and back to the application. Verify that a page available only to signed-in users loads in that session, then save the profile. Browserless profiles store cookies, localStorage, and IndexedDB entries, which can cover more authentication state than cookies alone.

Request a screenshot with the saved profile

Browserless uses a POST request to /screenshot, with the API token in the token query parameter. The authenticated-profile guide shows the profile attached to the screenshot endpoint as a query parameter. The example below uses placeholders for your Browserless hostname, token, profile name, and protected page URL; substitute the endpoint and values from your account documentation.

curl -X POST 'https://YOUR_BROWSERLESS_HOST/screenshot?token=YOUR_API_TOKEN&profile=YOUR_PROFILE_NAME' \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "https://YOUR_AUTHORIZED_SITE.example/account",
    "options": {
      "fullPage": true,
      "type": "png"
    }
  }' \
  --output account.png

Browserless’s documented request accepts a page URL and optional Puppeteer-style screenshot options. PNG is the quickstart default; JPEG and WebP can be selected where supported. The URL and inline HTML are alternatives: do not include both in one request. This guide does not invent a real Indian target URL because none was specified.

Use cookies directly when you already have a session

If you already have authorized session cookies, you can set them in a browser session before making the first request to the protected page. Copy each cookie’s recorded domain or URL and attributes such as secure and sameSite from the successful session. Do not guess or weaken those values. See Browserless’s guide to cookies and page setup.

Cookie injection gives explicit control over which cookies enter the session, but it may not restore authentication stored in localStorage or IndexedDB. For repeated captures, a profile can be more convenient because it stores these browser state types together. If a cookie-only session returns to the login page, use a profile or confirm what state the site requires.

Screenshot options and page behavior

The Browserless Screenshot API documents these relevant controls:

• fullPage: capture the full page rather than only the visible viewport.
• type and quality: choose an output format and, where applicable, image quality.
• clip: capture a specified region.
• viewport and deviceScaleFactor: control viewport dimensions and pixel density.
• Element selection: target a page element when a focused capture is preferable.
• Scrolling: trigger lazy-loaded content before capture when required.

Consult the current API reference for the accepted request shape and option details. For long pages, enable full-page capture and scroll to prompt lazy images or other deferred content to load. Full-page capture can produce a large image; use a clip or element capture when you only need one section.

Limits, reliability, performance, and cost

• Profile limits: Browserless documents a 2 MB captured-state limit and up to 50 distinct origins per profile. Keep profiles focused on the origins needed for the workflow.
• Session expiry: saved state can stop being accepted when a site expires or rotates its session. Re-authenticate through the normal flow and save a fresh profile when that happens.
• Login-dependent state: OTP, identity-provider, CAPTCHA, and device checks vary by site. The available research does not establish whether an unnamed site supports this workflow.
• Capture time: waiting for redirects and page content improves correctness but adds time. Full-page capture and lazy loading can take longer and return larger files than a viewport or clipped screenshot.
• Cost: Browserless pricing was not established by the sources used here. Check your account’s current plan and usage terms; do not infer a price from this guide.

Troubleshooting

Symptom	Likely cause	What to check
The screenshot shows a login form	The profile was saved before login finished, the final redirect did not complete, or the request names a different profile.	Verify the protected page in the setup session, save state afterward, and check the profile name on the request.
The identity-provider login succeeded, but the app is still signed out	The state may have been saved while the browser was still on the identity provider’s origin.	Wait for the redirect back to the application and verify access there before saving.
Cookies seem missing or are rejected	Cookies were applied after navigation, or their domain and security attributes do not match the original records.	Set cookies before the protected-page request and preserve their captured domain, secure, and sameSite values.
Cookie injection does not authenticate	The site may keep part of its state in localStorage or IndexedDB.	Try an authenticated profile, which captures these stores as well as cookies.
A profile cannot be saved or reused	Captured state may exceed 2 MB or include more than 50 distinct origins.	Reduce the state and origins included, then consult the profile guide for current limits.
The bottom of the page or images are missing	Capture is viewport-only or content is lazy-loaded.	Enable full-page capture and use the documented scrolling behavior to load deferred content.
The result is a challenge or an unexpected access page	The site may apply a CAPTCHA, bot check, or other access rule.	Do not assume automation is supported. Follow the site’s rules and use an authorized access method.
The screenshot request fails	The endpoint, token, profile parameter, request body, or target URL may be incorrect.	Compare the request with the Browserless Screenshot API and profile documentation, and check that the token and profile belong to the same account.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its one-call API returns a screenshot of a URL; see the ScreenshotNeo API documentation for options and authentication.

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,
)
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}`);

ScreenshotNeo removes cookie banners, newsletter 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 per month with no card; paid plans start at $5 for 3,000. A screenshot API does not replace an authorized login session for a protected page, so use it with pages accessible to the API request.

Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Does this work for every Indian login page?

No universal compatibility claim is possible. Login design, session storage, OTP, identity-provider redirects, and access rules differ by site.

Can I save the profile before the login redirect finishes?

Wait until the browser has returned to the application and the protected page is accessible, then save.

Is a profile the same as a cookie file?

No. Browserless profiles include cookies, localStorage, and IndexedDB, while cookie injection supplies cookies directly.

Can I send both HTML and a URL to the screenshot endpoint?

No. Browserless documents them as alternative inputs; use one or the other.

Sources

• Browserless Screenshot API
• Browserless Authenticated Profiles
• Browserless cookies and page setup
• Browserless REST APIs