How to Capture a PagePeeker Screenshot of a Password-Protected Web App
PagePeeker’s public docs don’t confirm authenticated capture. Learn how to check, capture a protected app with browser automation, and avoid exposing credentials.
Short answer: PagePeeker’s accessible public pages describe website screenshots and thumbnails, but the material reviewed does not document how to pass a password, session cookie, or other authenticated browser state. Its API navigation redirected to the homepage during research, so confirm current support with PagePeeker before relying on it to capture a logged-in page. If the app requires an interactive login or browser session, use browser automation and capture from that same authenticated session.
This guide explains how to identify the authentication method, what to verify with PagePeeker, and how to capture the protected page with Cloudflare Browser Run or Playwright when those approaches fit. Capture only pages you are authorized to view, and use a non-sensitive staging account for initial checks.
1. Identify how the app authenticates
“Password-protected” can refer to several different mechanisms. The right capture method depends on which one the target uses.
| Authentication method | What happens | What the capture needs |
|---|---|---|
| HTTP Basic Authentication | The server or proxy challenges the browser before serving the page. | A browser capture service that explicitly accepts HTTP authentication credentials. |
| Session cookie | The app recognizes a browser using a cookie issued after login. | A valid cookie for the right domain and path, supplied to the capture browser. |
| Authorization header or token | The app accepts a token or other header on the page request. | A capture browser that can send the target app’s required header. |
| Interactive login and browser state | A form, redirect, JavaScript flow, or multi-step login establishes the session. | Automation that signs in and captures using the same authenticated browser context. |
A screenshot provider’s API key authorizes use of that provider. It is separate from the target app’s password, cookie, or token. Supplying one does not authenticate the browser to the other.
2. Check what PagePeeker currently supports
PagePeeker describes itself as a screenshot and thumbnail service. Its official pages mention full-page screenshots for premium customers, account-based API access, and customization requests for premium customers. Its FAQ describes caching and API usage. The public material reviewed here does not explain authenticated captures using HTTP Basic credentials, target-site headers, injected cookies, or an interactive login. That documentation gap does not prove the feature is unavailable; it means you should verify it directly before building a workflow around it.
- Open the PagePeeker website and FAQ and follow its current API documentation from there.
- Ask PagePeeker support whether the current API can pass the specific authentication mechanism your app uses. Name the mechanism: Basic Auth, session cookie, authorization header, or form-based login.
- Ask how credentials are transmitted and stored, whether they can be scoped to a single capture, and how the API indicates that authentication succeeded.
- Test with an authorized staging page and inspect the image itself. A successful HTTP response can still contain a login form, access-denied page, or incomplete app.
PagePeeker’s listed prices and limits can change. Its pricing page, accessed on October 3, 2026, listed Basic at $5.99/month, Advanced at $39.99/month, and custom pricing for Premium, with different call limits, caching periods, and image options. Check the current PagePeeker pricing page for terms before choosing a plan. Do not infer that a plan supports authenticated capture from its screenshot or full-page options.
3. Choose a capture path for the authentication type
HTTP Basic Authentication or a session cookie
Use a browser capture service whose current documentation explicitly supports the method. Cloudflare Browser Run’s screenshot endpoint documents an authenticate object for HTTP authentication challenges and supplying cookies with the request. These solve different cases: HTTP authentication credentials handle a Basic Auth challenge, while cookies carry an existing app session. A cookie must be valid and scoped so the target page receives it.
See the Cloudflare Browser Run screenshot endpoint documentation for its current request format and options. Treat cookies as credentials: they can grant account access until they expire or are revoked.
Authorization header or token
If the page request accepts a target-app authorization header, use a browser service that can set extra request headers. Cloudflare’s documentation describes setting extra HTTP headers. Confirm that the header reaches the requests that need it; a header attached to the initial document request may not authenticate a separate API call made by the app. The screenshot provider’s own API key remains a separate credential.
Interactive login or a browser-state flow
When login involves form submission, redirects, client-side state, or multiple steps, automate the login and capture in the same browser context. Playwright documents saving and reusing authenticated browser state for tests. That state can contain cookies and headers that enable account impersonation. Store it as a secret, keep it out of source control, and restrict who and what can read it.
See Playwright’s authentication guidance for the supported storage-state workflow. Browser automation is especially useful when the app cannot be authenticated by a single cookie or request header.
4. Automate login and capture with Playwright
This Node.js example shows the general flow: read secrets from environment variables, log in, wait for an app-specific element, and save a screenshot from the authenticated page. Replace the selectors and URL with those for your app. It uses Playwright’s locator and page APIs; install Playwright and its browser in your project using the official setup guide.
import { chromium } from 'playwright';
const appUrl = process.env.APP_URL;
const appUsername = process.env.APP_USERNAME;
const appPassword = process.env.APP_PASSWORD;
if (!appUrl || !appUsername || !appPassword) {
throw new Error('Set APP_URL, APP_USERNAME, and APP_PASSWORD');
}
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext();
const page = await context.newPage();
try {
await page.goto(appUrl, { waitUntil: 'domcontentloaded' });
await page.getByLabel('Email').fill(appUsername);
await page.getByLabel('Password').fill(appPassword);
await page.getByRole('button', { name: 'Sign in' }).click();
// Wait for a page element that only appears after successful login.
await page.getByRole('heading', { name: 'Dashboard' }).waitFor({
state: 'visible',
timeout: 30000
});
await page.screenshot({ path: 'protected-dashboard.png', fullPage: true });
} finally {
await browser.close();
}
Set APP_URL, APP_USERNAME, and APP_PASSWORD in your local secret manager or shell environment; do not commit them. If the login flow uses different labels or a one-time verification step, update the locators and authentication flow accordingly. The dashboard heading is a readiness check, not proof by itself that the image is correct: inspect the output for the expected user and page.
5. Verify the result and protect credentials
- Confirm the expected page is visible. Check for the app’s authenticated content, not just an image file or HTTP success.
- Wait for meaningful readiness. For a JavaScript-heavy dashboard, wait for a selector that appears when the needed content is rendered. A fixed delay may be insufficient on a slow run and wasteful on a fast one.
- Check the image for failure states. Look for a login form, authorization error, blank section, loading spinner, or stale dashboard.
- Use least-privilege credentials. Prefer a staging account or a restricted account that can access only the page needed for capture.
- Keep secrets out of URLs and logs. Avoid putting passwords, cookies, bearer tokens, or saved browser state into public screenshot links, shared logs, repositories, or client-side code.
- Expire or revoke temporary access. Rotate credentials or revoke sessions when the capture job no longer needs them.
For recurring jobs, decide how the workflow handles expired sessions, login challenges, and app changes. Fail closed: if the authenticated ready element does not appear, report the capture as unsuccessful rather than treating a sign-in screen as the requested screenshot.
6. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server for developers. Its API supports custom headers, cookies, and Authorization, which can be useful when a page accepts those credentials directly. One GET request returns an image or PDF. This does not replace an interactive login flow that must first establish browser state; for that, use browser automation in the authenticated session.
See the ScreenshotNeo API documentation for the request options. Example request:
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are never billed. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card required.
7. Performance, reliability, and cost
Performance
- Wait for the selector that represents usable page content. Avoid waiting for every network connection to become idle if the app keeps polling or streaming.
- Capture only the area you need when a full-page image is unnecessary. Large pages can take longer to render and produce larger files.
- Reuse an authenticated browser context only within a trusted job boundary. Do not share one user’s session state across unrelated tenants or users.
Reliability
- Authentication can expire or be invalidated. Detect login redirects and missing authenticated selectors explicitly.
- Cookie domain, path, and expiry affect whether the browser sends a session cookie. Verify them against the target page and its redirects.
- Apps may load dashboard data after the initial HTML. Wait for the data-bearing element, then inspect the resulting screenshot.
- Keep a failure result distinct from a valid screenshot. Save enough operational detail to diagnose the stage that failed, but redact credentials and session material.
Cost
Compare the current provider pricing, call quotas, cache behavior, and whether a plan includes the output dimensions and full-page mode you need. PagePeeker’s FAQ says its renders are cached for several days and that displaying a cached thumbnail, requesting a new render, checking availability, and other API calls count toward API usage. Confirm the current billing rules and authenticated-capture support with the provider before estimating costs. Browser automation also has operational costs: browser runtime, maintaining selectors when the app changes, and safely managing login secrets.
8. Troubleshooting
| Symptom | Likely cause | What to check or fix |
|---|---|---|
| The result is a login page | The capture was unauthenticated, login failed, or a session expired. | Verify PagePeeker’s current auth support; check the login flow and wait for an authenticated-only element. |
| HTTP 401 or 403, or an access-denied page | Missing, invalid, expired, or incorrectly scoped credentials; possibly a separate authorization check. | Identify whether the app expects Basic Auth, a cookie, or a header. Confirm the credential is sent to the correct host and path. |
| Cookie works locally but not in the capture browser | The cookie may be expired, host-only, path-scoped, or tied to a browser context. | Use a fresh authorized session and check cookie scope and expiry. Do not paste a live cookie into a public URL or log. |
| Dashboard is blank or partly loaded | Capture ran before client-side data or images finished rendering. | Wait for an app-specific ready selector or content state, then capture and inspect again. |
| Login automation cannot find a field or button | Selectors do not match the current form, or the login UI is inside a frame or changed layout. | Inspect the page structure in a safe environment and update locators. Handle frames or extra login steps if the app uses them. |
| Login succeeds in a normal browser but fails in automation | The flow may require an extra verification step, browser state, or an interaction not covered by the script. | Follow the app’s authorized login flow in the same automation context; do not bypass its access controls. |
| Image contains the wrong user’s data | Shared or stale session state was reused. | Use isolated contexts and account-specific state; discard and recreate the session before capturing. |
| PagePeeker call succeeds but authenticated support remains unclear | A successful thumbnail response does not establish that credentials were accepted. | Inspect the image and ask PagePeeker support about the exact auth mechanism and current API behavior. |
9. Frequently asked questions
Can PagePeeker capture a page behind a login?
The public PagePeeker material reviewed does not document authenticated capture. Confirm the current API capability with PagePeeker before relying on it for a protected page.
Can I pass my normal website password in the screenshot URL?
Do not put a password in a URL. URLs can be recorded in browser history, logs, analytics, and referrer data. Use a documented credential mechanism and protect it as a secret.
Does a screenshot API key log in to my web app?
No. The screenshot API key authorizes the capture service. The target app needs its own supported authentication method.
What if the app uses single sign-on?
Use the app’s authorized sign-in flow in browser automation if a cookie or header alone cannot establish the session. Follow the identity provider’s requirements and verify the authenticated page before saving the image.
Is a cached screenshot proof that authentication still works?
No. A cached image can be older than the current session or page state. Check the provider’s cache behavior and request a fresh capture when you need current authenticated content.


