How to Capture Password-Protected Pages with ShrinkTheWeb

Direct answer: ShrinkTheWeb’s available documentation does not explain how to authenticate to a password-protected destination page. Its historical setup guide covers ShrinkTheWeb account keys and screenshot settings, but does not document destination-site Basic Auth, session cookies, custom headers, or automated login. That is a documentation gap, not proof that the current service cannot support protected captures. Confirm the current method with ShrinkTheWeb before sending it credentials or session data.

ShrinkTheWeb is described as a service for caching and displaying website screenshots or thumbnails through its API. The Drupal setup guide, last updated March 4, 2019, describes an Access key, a Secret key, and screenshot options. The related guide lists specific-page capture, custom size, full-length screenshots, viewport dimensions, delay, and image quality, but does not list destination-page credentials. Read the ShrinkTheWeb Drupal setup guide and related module documentation.

There is no verified ShrinkTheWeb authentication parameter or complete, runnable ShrinkTheWeb request for a protected page in these sources. Do not copy a guessed parameter or send a site password in a query string. First identify the authentication mechanism and ask ShrinkTheWeb for current instructions that match it.

1. Identify what “password-protected” means

The capture method depends on how the destination grants access. These mechanisms are different, and support for one does not establish support for another.

Protection type	How it works	What to ask ShrinkTheWeb
HTTP Basic Authentication	The server challenges a request before returning the page. A client supplies credentials for the challenge.	Does the current service accept Basic Auth for the destination? What is the exact documented parameter format, and how are credentials handled across redirects?
Website login form	A user submits a form; a successful login commonly establishes session state, often through cookies.	Does the service support session cookies or an authorized browser login flow? Can it handle the site’s JavaScript and login steps?
Token or custom-header access	The site expects an authorization token or another header on requests.	Are custom headers supported for the destination? How are they scoped to the intended origin and handled after redirects?

These are general categories, not ShrinkTheWeb features established by the cited guides. Ask the site administrator if you do not know which one protects the page.

2. Verify ShrinkTheWeb support before sending secrets

Confirm you are authorized to access and capture the page.
Identify whether it uses Basic Auth, a login-created session, or a token/header.
Ask ShrinkTheWeb for its current documentation and exact procedure for that mechanism. Ask about redirect handling, JavaScript-rendered pages, credential scope, and whether authentication values may be recorded in logs.
Use the least-privileged account or token that can load the required page. Keep the ShrinkTheWeb API credentials separate from the destination site’s credentials or session.
Capture a test page and inspect the resulting image. Confirm it shows the intended authorized content, rather than a login screen, access-denied page, or error.

The available ShrinkTheWeb sources do not specify a credential security model. Avoid putting passwords, tokens, or session cookies in public code, client-side pages, or logs. Send secrets only through a vendor-supported mechanism after confirming how it works.

3. Local browser capture when the service cannot authenticate

If ShrinkTheWeb does not document a compatible method, an authorized browser session is one possible route. Browser automation can perform a site’s login flow and save a screenshot locally. The following example is a generic Playwright pattern, not ShrinkTheWeb code. It demonstrates HTTP Basic Auth, the simplest case. It will not automatically solve MFA, CAPTCHA, bot checks, IP restrictions, or a multi-step login flow.

Install Playwright and its Chromium browser:

npm init -y
npm install playwright
npx playwright install chromium

Save this as capture-basic-auth.mjs. Provide credentials through environment variables so they are not embedded in the file:

import { chromium } from 'playwright';

const target = process.env.TARGET_URL;
const username = process.env.BASIC_AUTH_USER;
const password = process.env.BASIC_AUTH_PASSWORD;

if (!target || !username || !password) {
  throw new Error('Set TARGET_URL, BASIC_AUTH_USER, and BASIC_AUTH_PASSWORD');
}

const browser = await chromium.launch({ headless: true });
try {
  const context = await browser.newContext({
    httpCredentials: { username, password },
    viewport: { width: 1440, height: 1000 },
  });
  const page = await context.newPage();
  const response = await page.goto(target, {
    waitUntil: 'domcontentloaded',
    timeout: 60000,
  });

  console.log(`HTTP status: ${response?.status() ?? 'no main response'}`);
  await page.screenshot({ path: 'protected-page.png', fullPage: true });
  await context.close();
} finally {
  await browser.close();
}

Run it in a shell, substituting your authorized URL and credentials:

TARGET_URL='https://internal.example/report' \
BASIC_AUTH_USER='capture-user' \
BASIC_AUTH_PASSWORD='use-a-secret-manager-or-temporary-shell-value' \
node capture-basic-auth.mjs

For a normal login form, use a site-specific script: navigate to the sign-in page, fill the correct fields, submit, wait for a reliable post-login selector, then navigate to the protected URL and capture it. Field selectors and success conditions vary by site, so there is no safe universal login script. Do not bypass MFA or access controls; use an approved test account or an administrator-provided capture route.

Check the capture itself

Check the HTTP status when available, but do not treat a successful response alone as proof that the page is authenticated.
Inspect the screenshot for a login form, access-denied message, missing content, or unexpected redirect.
Wait for a page-specific element that only appears after authorization before capturing.
If the page relies on lazy loading, scroll or wait for the required content before taking a full-page image.

4. Troubleshooting protected captures

Symptom	Likely cause	What to do
The screenshot shows a login page	Authentication was not supplied, expired, or was for a different login mechanism.	Identify the mechanism and confirm ShrinkTheWeb’s current support and syntax. For local browser capture, verify credentials and wait for a post-login element.
Basic Auth works in a browser but not through the API	The API request may not support destination Basic Auth, or the parameter format is unknown.	Do not guess parameter names. Ask ShrinkTheWeb for a current example and test against a page you are authorized to access.
A cookie or token request redirects to sign-in	The session may have expired, be scoped to another host or path, or require additional state.	Renew the authorized session and confirm the required cookie/header scope with the service or site administrator. Do not paste a live session into shared logs.
The page is blank or incomplete	Client-side rendering, delayed content, blocked resources, or an authentication error may prevent the expected page from rendering.	Check the page manually, use a page-specific wait condition in browser automation, and ask the vendor about JavaScript rendering and wait controls.
Authentication breaks after a redirect	The destination may redirect to another hostname or authentication endpoint; credentials may not apply there.	Ask how the capture service scopes credentials across redirects. Never forward secrets to an unintended origin.
Login requires MFA, CAPTCHA, or an interactive challenge	A scripted or hosted capture may not be able to complete the challenge.	Use an approved authorized browser workflow, a dedicated test account, or a capture-specific access method supported by the site. Do not attempt to defeat the challenge.
The Drupal module appears obsolete or unsupported	Drupal.org’s status concerns the Drupal integration, not definitive current service status.	Verify the current ShrinkTheWeb service and API directly. Do not infer that the underlying service is unavailable solely from module status.

5. Performance, reliability, and cost considerations

Protected pages add work beyond a public screenshot: authentication, redirects, client-side rendering, and delayed content can all affect whether the intended page is captured. Set a timeout suited to the site and wait for a meaningful content condition instead of relying on a fixed short delay. Verify the image output as part of the workflow; a returned file can still contain a login or error page.

For repeated captures, prefer a dedicated least-privilege account and a controlled refresh process for credentials or sessions. Keep secrets out of source control and sanitize application logs. The cited ShrinkTheWeb materials describe a local thumbnail cache and configurable cache duration in its Drupal setup, but do not establish current pricing, authenticated-capture billing, quotas, service reliability, or present-day API behavior. Confirm those details with the vendor before estimating production cost or building a dependency on it.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its API supports custom headers, cookies, and Authorization, which can be relevant to authenticated captures; use those options only in accordance with the target site’s access rules and the current ScreenshotNeo documentation. This is an alternative, not a ShrinkTheWeb instruction. The standard one-call example captures a public page:

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

For a protected destination, consult the docs for the exact supported header, cookie, or Authorization configuration and use the least access needed. 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; 1,000 screenshots a month are free with no card, and paid plans start at $5 for 3,000. Sign up free for 1,000 screenshots a month, with no card required.

FAQ

Does a ShrinkTheWeb Access key authenticate me to the destination website?

The historical setup guide describes Access and Secret keys for the ShrinkTheWeb account. It does not say they authenticate to a protected destination. Treat these as distinct credentials unless current ShrinkTheWeb documentation says otherwise.

Does the Drupal module’s unsupported status mean ShrinkTheWeb is offline?

No. The Drupal.org status applies to the Drupal integration and does not establish whether the underlying service currently operates. Check with ShrinkTheWeb.

Not as written: it handles HTTP Basic Auth. A form login needs site-specific steps and selectors, and may involve MFA or other challenges.

What should I send ShrinkTheWeb when asking about support?

Describe the authentication type without sending a real password or live session. Ask for the current request format, redirect behavior, credential scope, and handling of JavaScript-rendered pages.