How to Capture a Website Screenshot Behind a Login with GrabzIt

To capture a page behind a login with GrabzIt, give the capture the same authenticated session as a signed-in browser. For a one-off or web-interface workflow, GrabzIt recommends importing a cookie file exported from the signed-in browser. For an automated application, supply the required session cookies from server-side code. If the capture shows the login page, the usual cause is missing, expired, or incorrectly scoped session cookies.

Use these methods only for accounts and pages you are authorized to access. Session cookies act like credentials: anyone who obtains a valid one may be able to use that session.

1. Choose the right login method

Method	Best for	Important limit
Cookie file import	A one-off capture or recurring capture configured in GrabzIt’s web interface	The exported file must include the cookies required by the page, including relevant subdomain cookies.
Programmatic cookies	Automated captures where your application supplies session state	Use a server-side integration. Browser JavaScript cannot read HTTP-only cookies.
Submit page HTML	A page whose HTML can be sent to the capture API	Its CSS, JavaScript, images, and other required resources must also be accessible.
Post a login form	A limited flow where a successful form post redirects directly to the page you want	This is not general-purpose browser login automation.
HTTP basic authentication	A site protected by the browser’s basic-auth prompt	This applies to HTTP basic authentication, not ordinary website login forms.

GrabzIt describes cookie import as its easiest and most reliable way to replicate a user session. For a program that captures on behalf of different users, programmatic cookies are usually more suitable because the session can be selected at runtime. See [GrabzIt’s cookie import guidance](https://grabz.it/support/article/how-do-you-take-a-screenshot-from-behind-a-login/) and [API overview](https://grabz.it/api/).

2. Import a browser cookie file for a manual capture

1. Sign in to the target site in a browser using an account authorized for the capture.
2. Export the relevant cookies in the Netscape cookie-file format. Each text-file line represents a cookie and includes fields such as domain, path, expiration, and value.
3. Check that the export includes cookies for the application and any authentication or API subdomains needed to render the target page.
4. In GrabzIt, configure the capture to use the cookie file, then capture the page URL.
5. Inspect the output. Confirm that it shows the intended signed-in page and that protected images or data loaded.

Cookie exports can contain multiple cookies for one session. Do not assume that a single cookie is sufficient. GrabzIt notes that missing cookies, including subdomain cookies, can result in an incomplete capture or a redirect to the login screen.

Cookie import is convenient for a stable account and a recurring capture set up through the web interface. Refresh the export when the session expires or the site rotates its session cookies. Prefer a dedicated, low-privilege account for capture jobs.

3. Supply session cookies from server-side code

For automation, obtain the session through an authorized login or session-management process in your own application, then pass the cookies required for the target page using the cookie-setting method in your GrabzIt language library. The support article recommends server-side code because HTTP-only session cookies are not readable from client-side JavaScript.

GrabzIt’s API has language-specific references and cookie methods. Use the exact cookie method and parameter names for your chosen library; do not assume that examples or option names are identical across SDKs. Start with the [GrabzIt API documentation](https://grabz.it/api/) and the [Node.js API reference](https://grabz.it/api/nodejs/).

// Integration outline: use the cookie-setting method documented for your GrabzIt SDK.
// Keep this code on your server. Do not put session values in browser JavaScript.
const targetUrl = 'https://app.example.com/reports';
const sessionCookies = [
  // Supply every required cookie with the domain and path expected by the SDK.
  // Read values from your server-side session store or authorized login flow.
];

// 1. Create the GrabzIt client with server-side application credentials.
// 2. Set the required session cookies using the SDK's documented cookie method.
// 3. Request a capture of targetUrl and save or retrieve the resulting image.
// 4. Check the capture status and inspect the output for the signed-in page.

This outline intentionally leaves SDK calls as placeholders: the cookie method and capture lifecycle are library-specific, and the available documentation should be followed for the language you use. Do not paste a live cookie into source control or a public issue.

Keep credentials and cookies private

• Keep the GrabzIt application key and secret on the server. Never expose the secret in client-side code.
• Store session cookies in a secret manager or protected server-side session store, and limit access to the capture worker.
• Restrict API access by domain and IP where appropriate. For GrabzIt’s JavaScript API, authorize only domains allowed to use the application key.
• Use a least-privilege account, rotate or replace session material when it expires, and avoid logging cookie values.
• Review the target organization’s data-handling requirements before sending authenticated page content to a hosted capture service.

GrabzIt states that imported cookie files are transmitted over HTTPS, stored securely, used only for captures initiated by the account holder, and inaccessible to other users. That is the vendor’s own security statement; assess it alongside your organization’s requirements. Its API overview also recommends protecting application credentials and describes restricting access by domain and IP. [API overview](https://grabz.it/api/) · [JavaScript API authorization guidance](https://grabz.it/api/javascript/)

4. Use the other documented approaches only when they fit

Submit the page HTML

GrabzIt’s support guidance describes sending page HTML through its JavaScript API. This can work when you already have the rendered or source HTML and all linked resources needed for the image are accessible to the capture service. It will not make protected CSS, scripts, or images available by itself. If the page depends on a live authenticated session to fetch those resources, cookie-based capture is a better fit.

Post a login form

GrabzIt documents posting a login form for the narrow case where the successful submission redirects to the desired URL, or where the next page after the login screen is the target. Do not treat a form post as a general solution for multi-step authentication, interactive challenges, or a site-specific browser flow. Check the target site’s authorized integration options if the redirect does not establish the session for the capture.

HTTP basic authentication

If the browser displays an HTTP basic-auth prompt, provide the credentials through the relevant GrabzIt integration. This mechanism is distinct from a normal HTML login page. Keep those credentials server-side and scoped to the minimum access needed.

5. Capture output and dimensions

GrabzIt supports screenshot and conversion outputs including PDF and DOCX. In its ASP.NET image-capture documentation, supported image formats include JPG, PNG, WEBP, BMP, and TIFF. That reference documents BrowserHeight = -1 for a full-length screenshot and output width and height of -1 to match browser dimensions. These are ASP.NET-specific parameter examples; verify the equivalent settings in the language library you use. [ASP.NET image capture reference](https://grabz.it/api/aspnet/)

For a long dashboard or report, decide whether you need a viewport screenshot or a full-page capture. A full-page image may be large and can expose more sensitive information than a viewport capture. Check output dimensions and format against the downstream system that will store or display the image.

6. Troubleshoot login-protected captures

Symptom	Likely cause	What to do
The screenshot shows the login screen	A required cookie is missing, expired, or not sent for the correct domain or path.	Re-export the signed-in session or inspect all required cookies, including subdomain cookies. Confirm the session still works in a normal browser.
The page shell appears, but data or images are missing	Some resources use separate authentication cookies or are hosted on another restricted domain.	Identify the resource host and include the required authorized session cookies. If using submitted HTML, make sure linked resources are accessible.
It works once, then redirects to login	The session expired or the site rotated its session state.	Refresh the cookie export or obtain current cookies through the server-side session flow. Avoid relying on a permanent cookie file.
The cookie file is rejected or has no effect	The export may not be in the Netscape format, or its domain, path, or expiry fields may not match the page.	Export in the supported format and check the text file’s cookie records and scopes before importing.
Basic-auth credentials do not unlock the page	The site uses a regular login form rather than HTTP basic authentication.	Use session cookies or the narrowly applicable form-post approach instead.
The page is incomplete despite valid cookies	The capture may require inaccessible resources, additional page interaction, or a site-specific flow.	Check required resources and the language SDK’s capture status. Do not assume every authentication design is supported; validate the exact authorized flow.

GrabzIt’s Node.js API reference describes checking whether a capture is processing, cached, or expired, and includes custom cookie methods. If your application reports status, use the language-specific reference rather than assuming all SDKs expose identical status values or method names. [Node.js API reference](https://grabz.it/api/nodejs/)

7. Performance, reliability, and cost considerations

• Session freshness: Cookie-based captures are only as reliable as the session lifetime. Plan how the job obtains or refreshes authorized session cookies.
• Render dependencies: A page can authenticate successfully while its CSS, images, API calls, or scripts still fail. Validate the rendered output rather than treating a successful request as proof of a complete capture.
• Capture size: Full-page images and PDF output can take more time and storage than a viewport image. Choose dimensions and output format based on the actual use.
• Polling and cache state: For asynchronous workflows, follow the library’s documented capture-status and cache behavior. Avoid building assumptions around a status field from a different language SDK.
• Cost control: Protect the application key, restrict where it can be used, and monitor capture usage in your account. Keep automated jobs limited to the URLs and accounts they need.
• Security: Treat cookie files, session values, application secrets, and captured page contents as sensitive. A screenshot can reveal the same private data as the signed-in page.

The dossier does not establish universal support for every login flow or provide an independent performance benchmark. Multi-factor challenges, bot checks, and site-specific interactions should be evaluated for the exact site and an authorized account before depending on them.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. Its one-call API captures a URL as an image or PDF; see the API documentation for supported 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)
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}`);

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; paid plans start at $5 for 3,000. For pages that require login, use the documented custom headers or cookies options and only capture accounts you are authorized to access. Sign up for 1,000 free screenshots a month with no card.

FAQ

Why does my screenshot show the login page instead of the dashboard?

The capture likely lacks one or more current session cookies, or a cookie’s domain or path does not match the page. Check subdomain cookies as well as the main application cookie.

Can browser JavaScript read the session cookie for an automated capture?

HTTP-only cookies are not available to client-side JavaScript. Use an authorized server-side integration to supply session state.

Does a successful login-form POST always work?

No. GrabzIt documents it for a limited redirect scenario, not as general automation for arbitrary login flows.

Can I use this with a page protected by HTTP basic authentication?

Yes, that is a separate documented case. It applies when the browser presents a basic-auth prompt, not a normal login form.

Should I use my own administrator account?

Prefer a dedicated account with only the permissions required for the capture, as GrabzIt’s support guidance recommends using a less-privileged account when possible.