Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsIf an automated screenshot shows a login page instead of the page you can see while signed in, the browser taking the screenshot probably does not have a valid authenticated session—or it captured before the sign-in redirect finished. In Playwright, save browser storage after login, load that state into the screenshot browser context, and verify the final URL and a signed-in page element before capturing. If those checks fail, inspect the redirect chain and refresh the saved state.
Why the screenshot shows a logged-out page
A screenshot records what the browser has rendered; it does not sign you in or confirm that authentication worked. Your regular browser and an automation browser context are separate, so being signed in in one does not automatically sign in the other. A saved session may also have expired, or a redirect may still be taking place when the screenshot runs.
Common causes include:
- The screenshot context never loaded the saved authentication state.
- The state was saved before the login flow finished setting cookies or completing redirects.
- The saved session has expired or been revoked.
- The site redirected to a login or identity-provider page, but the script captured without checking the destination.
- A client-side redirect or delayed page rendering means navigation is not yet at the state the script expects.
The exact cause depends on the site, login method, browser context, and redirect trace. The checks below help distinguish these cases rather than assuming that a successful login-button click means authentication is complete.
Fix it in Playwright with saved authentication state
Playwright supports saving browser state after login and reusing it in later contexts. The state can include cookies and, depending on the application and configuration, other browser-side authentication data. The example uses a setup script to log in once, then a separate screenshot script to load the saved state and verify the result. Install Playwright first with npm install -D playwright.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall#1 Best Overall
1. Log in and save state only after authentication completes
Create auth.setup.js. Replace the example URL, selectors, and credentials with those for your site. Supply credentials through environment variables rather than committing them to source control.
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://example.com/login');
await page.getByLabel('Email').fill(process.env.TEST_EMAIL);
await page.getByLabel('Password').fill(process.env.TEST_PASSWORD);
await page.getByRole('button', { name: 'Sign in' }).click();
// Wait for the completed sign-in destination, not just the button click.
await page.waitForURL('https://example.com/account');
await page.getByRole('button', { name: 'Account menu' }).waitFor();
await context.storageState({ path: 'playwright/.auth/user.json' });
await browser.close();
})().catch(error => {
console.error(error);
process.exit(1);
});Use a URL pattern if your application has variable path or query components, and choose a stable element that appears only for authenticated users. A login flow can set cookies across several redirects, so save state after reaching the final destination or confirming an authenticated UI cue. The Playwright authentication guide documents both checks and state reuse: Playwright authentication.
Rank #2
![Free Fling File Transfer Software for Windows [PC Download]](https://m.media-amazon.com/images/I/41Vq6ZqHfjL._SL160_.jpg)
- Intuitive interface of a conventional FTP client
- Easy and Reliable FTP Site Maintenance.
- FTP Automation and Synchronization
2. Load the saved state, verify the destination, then capture
Create capture.js and use the same origin and account-specific state file as the setup flow:
const { chromium, expect } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
storageState: 'playwright/.auth/user.json'
});
const page = await context.newPage();
const response = await page.goto('https://example.com/account/reports', {
waitUntil: 'domcontentloaded'
});
console.log('Final URL:', page.url());
console.log('Navigation status:', response ? response.status() : 'no document response');
await expect(page).toHaveURL(//account/reports(?:[?#].*)?$/);
await expect(page.getByRole('button', { name: 'Account menu' })).toBeVisible();
await page.screenshot({ path: 'account-report.png', fullPage: true });
await browser.close();
})().catch(error => {
console.error(error);
process.exit(1);
});The URL assertion catches a redirect to a login route; the authenticated-element assertion checks that signed-in content actually rendered. Adjust the URL pattern and element to match the application. A navigation response corresponds to the last redirect response, not necessarily every hop in the chain; client-side navigation can also continue after the document response. See the Playwright Page API, navigation guide, and PageAssertions API.
Recommended Free Tools
3. Protect the saved state file
Storage-state files can contain cookies and headers that let someone impersonate the account. Keep them out of source control and restrict access to them. Add the file and its directory to .gitignore, for example:
playwright/.auth/Do not place a real account’s state file in a public artifact or share it as a debugging attachment. Playwright explicitly warns that state files may contain sensitive authentication data: Authentication state security guidance.
Diagnose the redirect before changing the script
- Record the final URL. Log
page.url()immediately before capture. If it is a login URL, the screenshot is reflecting the browser’s actual destination. - Check an authenticated UI cue. Wait for a stable account menu, user name, or signed-in-only heading. If the URL looks right but this check fails, the page may not have rendered authenticated content yet.
- Confirm the correct context loaded the state. Pass
storageStatewhen creating the same browser context used for navigation. State is not automatically shared across isolated contexts. - Regenerate stale state. Run the login setup again and replace the saved file if the session expired or was revoked.
- Inspect redirect hops if the cause remains unclear. Playwright requests expose redirect relationships. The Network and Request API documentation explains how to inspect them: Network and Request API.
- Capture only after both checks pass. A screenshot call captures the current page; it does not validate login or wait for your application’s authenticated state by itself.
Choose between logging in each run and reusing state
| Approach | Useful when | Trade-off |
|---|---|---|
| Log in within each test or capture run | You need an isolated, freshly authenticated session for each run. | Repeats the login flow and can make runs slower; login itself must still be awaited and verified. |
Run a setup flow and reuse storageState |
Many captures or tests use the same authenticated account. | The state can expire and must be regenerated; protect the file as a credential. |
| Use separate saved states | Tests need different roles or accounts. | Maintain and load the correct state file for each role. |
Playwright’s authentication guide covers repeated login, shared state, and using separate state files for different roles: Authentication.
Troubleshooting common failures
The saved state exists, but the page still redirects to login
- Verify that the screenshot context is created with the exact state-file path and that the file is readable.
- Regenerate the state by logging in again, then confirm the setup script waited for the final URL or authenticated UI before saving.
- Inspect redirect requests to see whether the site rejects the session immediately or redirects later in the flow.
The final URL is correct, but the screenshot still looks logged out
- Wait for a signed-in-only element to become visible before capture; reaching a route does not prove that its content finished rendering.
- Check whether the app uses client-side navigation or delayed rendering after the initial document load.
- Use a UI assertion as well as a URL assertion so the script fails rather than saving an ambiguous image.
The setup script saves state too early or times out
- Do not use the completion of the sign-in click as the only signal. Wait for the final destination or a stable authenticated element.
- If a URL is dynamic, use a suitable URL pattern and a site-specific UI cue instead of an overly exact URL string.
- For a client-side redirect, wait on the expected destination or visible application state rather than assuming the first navigation response marks completion.
The flow works locally but fails in automation
- Check that the automated run is using the same intended account and state file, not a fresh context without saved state.
- Check whether the saved session has since expired. Re-run setup and confirm the replacement file is being loaded.
- Use redirect tracing to identify the request where the destination changes. The first wrong destination is more useful than repeatedly changing screenshot timing.
Or skip the browser setup
For captures that can be authenticated with request cookies or headers, ScreenshotNeo can take a screenshot or PDF through one request. Its custom-cookie and custom-header options may suit sites that accept those credentials; the example below does not log into a site or transfer a Playwright state file, so it is not a drop-in fix for every interactive login flow. See the ScreenshotNeo API documentation for authentication-related options and other parameters.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and responses indicate the page verdict and billing status. It also has an MCP server with screenshot, page-info, and PDF-capture tools for AI agents. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Sign up for ScreenshotNeo: 1,000 screenshots a month free, no card required.
Frequently Asked Questions
Can Playwright storage state be used for every kind of login?
Not necessarily. The state must represent what the target application accepts, and some authentication flows require additional site-specific handling. Verify the resulting session by checking the final URL and an authenticated page element.
Does a screenshot call wait until a page is signed in?
No. It captures the current page. The script must establish and verify the authenticated state before calling the screenshot method.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
