Why Does Playwright Return Blank Screenshots for Some URLs in a Batch?

A blank-looking screenshot for only some URLs in a Playwright batch does not point to one specific cause. Check, for each URL, that navigation reached the expected page and inspect its HTTP response; then wait for the page content you need and verify that the screenshot uses the Page created for that URL. Navigation completion and visual readiness are separate.

Start by logging the input URL, final page URL, navigation status, title, and a representative content locator for every batch item. Save screenshots to unique filenames tied to their input URLs. If a failing URL works by itself in the same browser environment, investigate page assignment, page reuse, shared context settings, and output mapping. If it fails alone too, inspect its response and application-specific readiness.

1. Diagnose each URL before changing waits

1. Record the input and final URL. Redirects are possible; page.url() tells you where that Page ended up.
2. Inspect the navigation response. A successful page.goto() call does not mean the server returned a successful status. Playwright does not throw for valid HTTP error statuses such as 404 or 500.
3. Check page identity and content. Record the title and wait for a meaningful locator that should appear in the screenshot.
4. Capture to a unique path. Include an index or sanitized host so parallel captures cannot overwrite or obscure each other.
5. Reproduce one failing URL alone. Keep the browser engine, viewport, context settings, and headless mode the same.

Also attach console and page error listeners. They provide useful evidence when an application script fails before rendering. A screenshot symptom alone cannot identify the cause; the batch code, failing URLs, browser environment, and logs are needed to distinguish possibilities.

2. Runnable Playwright example: inspect and capture a batch

This Node.js example uses Playwright. It checks the response status, final URL, title, and a page-specific readiness locator; records browser errors; and gives every URL a distinct output filename. Replace the sample URLs and locator with values appropriate for your pages.

import { chromium } from 'playwright';

const urls = [
  'https://example.com/',
  'https://playwright.dev/',
];

const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({ viewport: { width: 1440, height: 900 } });

try {
  for (const [index, url] of urls.entries()) {
    const page = await context.newPage();
    const errors = [];

    page.on('console', message => {
      if (message.type() === 'error') errors.push(`console: ${message.text()}`);
    });
    page.on('pageerror', error => errors.push(`pageerror: ${error.message}`));

    try {
      const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30000 });
      const status = response?.status() ?? 'no main-resource response';

      // Replace this with a locator that represents the content needed in the shot.
      await page.locator('body').waitFor({ state: 'visible', timeout: 15000 });

      const title = await page.title();
      const finalUrl = page.url();
      const filename = `shot-${String(index).padStart(3, '0')}.png`;

      console.log(JSON.stringify({ input: url, finalUrl, status, title, filename, errors }));
      await page.screenshot({ path: filename, fullPage: true });
    } catch (error) {
      console.error(JSON.stringify({ input: url, error: String(error), errors }));
    } finally {
      await page.close();
    }
  }
} finally {
  await context.close();
  await browser.close();
}

The body locator is a minimal example, not a guarantee that a single-page application has rendered its meaningful content. Prefer a stable selector such as main h1, a product panel, or another element that must be visible in the image. If the response is null, log that explicitly; for example, navigation may have resulted in a download or another condition without a main-resource response.

3. Wait for content, not an assumed load state

waitForLoadState() is not a general visual-readiness check. If the requested state already occurred, it resolves immediately. Playwright notes that the method is usually unnecessary because actions auto-wait. For screenshots, wait for the page-specific content you need:

await page.goto(url, { waitUntil: 'domcontentloaded' });
await page.locator('main h1').waitFor({ state: 'visible', timeout: 15000 });
await page.screenshot({ path: 'page.png', fullPage: true });

Choose a readiness locator that reflects the page, not merely that the document exists. If the content is rendered after an API call, the heading or component is a more useful signal than the initial document event.

Do not add networkidle as the default fix. Playwright discourages using that state for testing and recommends web assertions to assess readiness. Pages with long polling, analytics, or other continuing requests may also make a network quiet period a poor proxy for visible content.

4. Check batch page assignment and shared context settings

A BrowserContext can contain multiple pages, and pages share context-level emulation settings. In a batch, confirm that each iteration navigates and captures the same Page, particularly if pages are reused, popups are involved, or jobs run concurrently. Log the URL immediately before capture and associate it with the screenshot path.

For parallel workers, use a fresh Page per task or maintain an explicit mapping from task to Page. Avoid shared mutable variables that can cause one task’s URL or output path to be used by another. Capture each screenshot to a unique filename, then verify the mapping in the diagnostic log.

5. Isolate the failure with the same environment

1. Take one URL that produced a blank image and run it alone.
2. Keep the browser engine, browser version, viewport, context emulation, and headless mode the same as in the batch.
3. If it works alone, inspect page reuse, task-to-Page mapping, shared context settings, concurrency, and filename collisions.
4. If it is still blank, inspect the response status, final URL, expected content locator, console errors, and page errors.
5. Compare a screenshot from the same environment before attributing a visual difference to the target site.

Screenshot appearance can vary with the host operating system, browser version, settings, hardware, power source, and headless mode. Reproducing under the same conditions helps separate environment differences from URL-specific behavior.

6. Visual regression is a separate problem

If the goal is to compare screenshots in Playwright Test, use its screenshot assertion:

import { test, expect } from '@playwright/test';

test('page screenshot is stable', async ({ page }) => {
  await page.goto('https://example.com/');
  await page.locator('main h1').waitFor({ state: 'visible' });
  await expect(page).toHaveScreenshot('example.png');
});

toHaveScreenshot() waits for two consecutive screenshots to match before comparing against the expected image. This is a visual comparison assertion available in the Playwright test runner; it is not a general page-ready wait for scripts run outside that runner.

7. Troubleshooting common causes

Symptom	Likely explanation	What to check or change
Navigation completed but screenshot is blank or an error page	The server returned an HTTP error status; goto() can return normally for statuses such as 404 or 500.	Inspect the response status and final URL. Handle error responses explicitly in the batch report.
Page shell appears, but expected content is missing	The application content had not rendered when capture began.	Wait for a stable, page-specific locator that represents the content to capture.
Only some parallel captures show the wrong page	A task may be using a reused or incorrectly assigned Page, or outputs may collide.	Log input URL and page.url() per task; use distinct filenames and verify Page ownership.
A wait returns immediately and does not help	The requested load state may already have occurred; it does not indicate that application content is ready.	Wait for the expected locator or use a Playwright Test assertion when doing visual comparison.
Adding networkidle hangs or remains unreliable	Network quiet is not a dependable visual-readiness condition for every application.	Remove it as the default and wait for the content needed in the screenshot.
Failure differs between local and CI runs	Browser rendering can vary by operating system, browser version, settings, hardware, power source, or headless mode.	Reproduce with matching browser and environment settings, then compare logs and screenshots.
No useful error appears in the batch output	The capture path may log only thrown exceptions and omit browser console or page errors.	Attach console and pageerror listeners and include those messages in each URL’s record.

8. Performance, reliability, and cost

For faster diagnosis, begin with a small batch or one failing URL, and collect compact per-URL metadata before increasing concurrency. Waiting for a specific visible element avoids treating broad network activity as the success signal. Set navigation and locator timeouts deliberately, and report timed-out URLs separately from HTTP error responses and successful captures.

For reliability, keep each capture’s URL, response status, final location, readiness result, and output path together. Reproduce failures under the same browser configuration. A retry may help with a transient navigation or application delay, but it does not fix a wrong Page mapping, a persistent HTTP error, or a readiness condition that never occurs.

With a self-hosted Playwright setup, the practical costs are browser compute, storage, and engineering time spent maintaining the browser environment and batch logic. There is no per-shot Playwright API charge described here; infrastructure and operational costs depend on how you run it.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and each response identifies the outcome in X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

For the full set of options and parameter names, see the ScreenshotNeo API documentation.

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

Free includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 shots; all features are available on every plan. See ScreenshotNeo for product details, then sign up free to get 1,000 screenshots a month with no card.

10. FAQ

Does a blank screenshot mean page.goto() failed?

No. Navigation can complete with a valid HTTP error response, and the application may still not have rendered the expected content. Check the response and a content locator.

Should I wait for networkidle before every screenshot?

No. Playwright discourages it as a testing readiness signal. Wait for the specific content the screenshot needs.

Can Playwright Test screenshot assertions make ordinary captures wait for stability?

toHaveScreenshot() is a Playwright Test visual comparison assertion. It waits for consecutive matching screenshots before comparison, but is not a generic readiness API outside the test runner.

Why does the same URL look different on another machine?

Browser rendering can vary with the operating system, browser version, settings, hardware, power source, and headless mode. Compare using a matching environment before diagnosing the page itself.