DEV Community: Vitalii Holben

How to take screenshots of password-protected pages with a screenshot API

Vitalii Holben — Fri, 10 Apr 2026 13:07:05 +0000

Not every page you need to screenshot is open to the world. Sometimes you need a screenshot of a service admin panel, an internal dashboard, a staging server, or a page behind basic auth. And that's where the problem starts: you send the URL to a screenshot API, and what comes back is a screenshot of the login form. The headless browser on the API side doesn't know your credentials and visits the page as a brand new user.

I want to walk through how to handle this. As an example, I'll use my own project fixheaders.com, a security headers scanner. It has a Filament admin panel, and I periodically need a screenshot of the dashboard showing scan counts without logging in manually every time.

I'll cover three authentication methods: cookies, custom HTTP headers, and Basic Auth. Each method comes with code examples in cURL, Node.js, and PHP.

Why a regular screenshot request won't work

When you ask a screenshot API (or Playwright, or Puppeteer) to capture a URL, the headless browser opens it as a completely new visitor. No session, no cookies, no saved credentials. If the page requires a login, the server sees an unauthenticated request and redirects to the login form. Or just shows it directly.

Here's what happens when you send a regular request to the fixheaders.com admin URL without any cookies:

curl -X POST https://screenshotrun.com/api/v1/screenshots \
  -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://fixheaders.com/admin"}'

We wait a few seconds and download the result:

curl -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  https://screenshotrun.com/api/v1/screenshots/SCREENSHOT_ID/image \
  -o screenshot-no-auth.png

Open the file and you see this:

The login form. This is exactly what the headless browser sees when it visits a protected URL without authentication. It's the same thing that happens when you open a private URL in an incognito window. The browser has no cookies, so the server treats you as a stranger.

The fix is to give the headless browser the same credentials your regular browser already has. There are a few ways to do that, depending on how the target site handles authentication.

Method 1: pass session cookies (the most common case)

Most web apps (Laravel, Django, Rails, WordPress, Filament, any admin panel) use cookie-based sessions. When you log in, the server creates a session and sends a cookie. Every subsequent request includes that cookie, and the server knows who you are.

The idea is simple: grab the session cookie from your browser and pass it to the screenshot API. The headless browser will send that cookie with the request, the server will see a valid session, and you'll get a screenshot of the actual dashboard, not the login page.

Step 1: find your session cookie

Open the site you want to screenshot (in my case, the fixheaders.com admin panel). Log in normally. Then open DevTools → Application → Cookies (in Chrome) or Storage → Cookies (in Firefox).

Look for the session cookie. In Laravel apps it's usually called laravel_session or a custom name from config/session.php. In my case it's fixheaders-session. The name varies across frameworks. In some apps it's PHPSESSID, in Django it's sessionid, in Rails it's _yourapp_session.

Copy the cookie value. It'll look something like this:

eyJpdiI6IkxMNk1DVjZhN0FKWjZ2a3...long_base64_string

Step 2: pass it to the screenshot API

Here's how to send that cookie with a screenshotrun API request.

cURL:

curl -X POST https://screenshotrun.com/api/v1/screenshots \
  -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://fixheaders.com/admin",
    "cookies": [
      {
        "name": "fixheaders-session",
        "value": "eyJpdiI6IkxMNk1DVjZhN0FKWjZ2a3...",
        "domain": "fixheaders.com"
      }
    ]
  }'

The cookies parameter takes an array of objects. Each one needs a name, value, and domain. The domain tells the browser which site to send the cookie to. Without it, the cookie might not get attached to the request.

Download the result the same way, using the ID from the response:

curl -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  https://screenshotrun.com/api/v1/screenshots/SCREENSHOT_ID/image \
  -o screenshot-with-auth.png

And here's what we get this time:

The actual dashboard. Scan counts, average score, recent checks. Exactly what I see when I'm logged in through the browser. One cookie made all the difference.

Node.js:

const response = await fetch("https://screenshotrun.com/api/v1/screenshots", {
  method: "POST",
  headers: {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://fixheaders.com/admin",
    cookies: [
      {
        name: "fixheaders-session",
        value: "eyJpdiI6IkxMNk1DVjZhN0FKWjZ2a3...",
        domain: "fixheaders.com",
      },
    ],
  }),
});

const { data } = await response.json();
console.log(data.id);

PHP (Laravel):

If you're working with PHP and haven't set up the screenshot API yet, I covered the full setup process in the PHP screenshot tutorial. Here's the short version for authenticated pages:

$response = Http::withToken(env('SCREENSHOTRUN_API_KEY'))
    ->post('https://screenshotrun.com/api/v1/screenshots', [
        'url' => 'https://fixheaders.com/admin',
        'cookies' => [
            [
                'name' => 'fixheaders-session',
                'value' => 'eyJpdiI6IkxMNk1DVjZhN0FKWjZ2a3...',
                'domain' => 'fixheaders.com',
            ],
        ],
    ]);

$screenshotId = $response->json('data.id');

After the request completes, poll the screenshot status or use a webhook to get notified when it's ready.

What can go wrong with cookies

Session expiration. This is the biggest one. Session cookies have a lifetime. In Laravel the default is 2 hours. After that, the session is invalid and the screenshot API will get the login page again. If you're automating this, you need to refresh the cookie periodically. One option is to write a script that logs in via HTTP (POST to the login endpoint with credentials), grabs the fresh session cookie from the Set-Cookie response header, and uses that for the screenshot request.

Multiple cookies. Some apps require more than one cookie. CSRF tokens, "remember me" cookies, or multi-cookie session setups. If the screenshot comes back as a login page even though you're sending the session cookie, check whether the site sets additional cookies during login. You can pass up to 20 cookies in a single screenshotrun request, which covers pretty much any setup.

HttpOnly and Secure flags. Session cookies are often marked as HttpOnly (can't be read by JavaScript) and Secure (only sent over HTTPS). These flags don't affect the screenshot API. The headless browser handles them the same way a regular browser does. Just make sure you're using HTTPS URLs.

SameSite cookies. If the cookie has SameSite=Strict, it might not get sent in certain cross-origin scenarios. With a screenshot API, the headless browser navigates directly to the URL (it's a top-level navigation, not a cross-origin fetch), so SameSite=Strict cookies are included normally.

Method 2: custom HTTP headers (API tokens and Bearer auth)

Not every protected page uses cookies. Internal tools, API documentation portals, and headless CMS interfaces sometimes protect pages with custom HTTP headers: an API token, a Bearer token, or a custom X-Auth-Token header.

If the page you need to screenshot checks for a specific header instead of (or in addition to) cookies, you can pass custom headers through the screenshot API.

cURL:

curl -X POST https://screenshotrun.com/api/v1/screenshots \
  -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://internal-tool.example.com/dashboard",
    "headers": {
      "X-Auth-Token": "your-internal-token-here"
    }
  }'

Node.js:

const response = await fetch("https://screenshotrun.com/api/v1/screenshots", {
  method: "POST",
  headers: {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://internal-tool.example.com/dashboard",
    headers: {
      "X-Auth-Token": "your-internal-token-here",
    },
  }),
});

PHP:

$response = Http::withToken(env('SCREENSHOTRUN_API_KEY'))
    ->post('https://screenshotrun.com/api/v1/screenshots', [
        'url' => 'https://internal-tool.example.com/dashboard',
        'headers' => [
            'X-Auth-Token' => 'your-internal-token-here',
        ],
    ]);

The headers parameter accepts an object where keys are header names and values are header values. You can send up to 20 custom headers per request.

One thing to watch out for: the Authorization header in the headers parameter is the one sent to the target page, not to the screenshotrun API itself. The API key for authenticating with screenshotrun goes in the top-level Authorization header of the HTTP request. The headers object is what the headless browser sends when loading the target URL. These are two different things, and it's easy to mix them up.

Method 3: Basic Auth for staging and htpasswd-protected sites

If you've ever password-protected a staging server with Nginx's auth_basic or Apache's .htpasswd, you know how it works. The browser shows a modal dialog asking for a username and password. Headless browsers can't interact with that dialog, so the request just fails or returns a 401.

The fix is simple: send the credentials as a Basic Auth header. The browser won't see the dialog at all because the server gets the credentials before it has a chance to ask for them.

cURL:

curl -X POST https://screenshotrun.com/api/v1/screenshots \
  -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://staging.example.com",
    "headers": {
      "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
    }
  }'

The Basic dXNlcm5hbWU6cGFzc3dvcmQ= part is just username:password encoded in Base64. You can generate it from the terminal:

echo -n "username:password" | base64
# Output: dXNlcm5hbWU6cGFzc3dvcmQ=

Node.js:

const credentials = Buffer.from("username:password").toString("base64");

const response = await fetch("https://screenshotrun.com/api/v1/screenshots", {
  method: "POST",
  headers: {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://staging.example.com",
    headers: {
      "Authorization": `Basic ${credentials}`,
    },
  }),
});

PHP:

$credentials = base64_encode('username:password');

$response = Http::withToken(env('SCREENSHOTRUN_API_KEY'))
    ->post('https://screenshotrun.com/api/v1/screenshots', [
        'url' => 'https://staging.example.com',
        'headers' => [
            'Authorization' => 'Basic ' . $credentials,
        ],
    ]);

This method works for any site that uses HTTP Basic Authentication. It's common on staging environments, dev servers, and some internal tools. If you're monitoring your staging after deployments, I wrote a separate article about why screenshots catch things logs miss that covers the reasoning behind this.

Combining cookies with other capture options

All three authentication methods work alongside the regular screenshot parameters. You can take a full-page screenshot of an authenticated dashboard in dark mode, at a mobile viewport, with cookie banners blocked. All in one request:

curl -X POST https://screenshotrun.com/api/v1/screenshots \
  -H "Authorization: Bearer $SCREENSHOTRUN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://fixheaders.com/admin",
    "cookies": [
      {
        "name": "fixheaders-session",
        "value": "your-session-cookie-value",
        "domain": "fixheaders.com"
      }
    ],
    "full_page": true,
    "dark_mode": true,
    "device": "mobile",
    "format": "webp"
  }'

I covered the full list of parameters (dark mode, device presets, CSS injection and element selectors) in the API documentation. If you haven't looked at the other capture options yet, the cURL examples article walks through each one with copy-paste commands.

Automating the login (when cookies expire too fast)

If you want to capture authenticated screenshots on a schedule (say, every hour for a dashboard you embed somewhere), manually copying cookies won't cut it. Sessions expire, and your screenshot will revert to a login page.

The workaround is to automate the login step itself. Instead of grabbing cookies from a browser by hand, write a script that logs in programmatically, extracts the session cookie, and passes it to the screenshot API.

Here's a Node.js example using plain fetch (if you need more context on the Node.js setup, check out the full Node.js tutorial):

async function getSessionCookie(loginUrl, email, password) {
  const response = await fetch(loginUrl, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, password }),
    redirect: "manual",
  });

  const setCookie = response.headers.get("set-cookie");
  if (!setCookie) {
    throw new Error("No Set-Cookie header in login response");
  }

  const match = setCookie.match(/(\w+[-_]session)=([^;]+)/);
  if (!match) {
    throw new Error("Could not find session cookie in Set-Cookie header");
  }

  return { name: match[1], value: match[2] };
}

// Usage
const cookie = await getSessionCookie(
  "https://fixheaders.com/login",
  "your@email.com",
  "your-password"
);

const response = await fetch("https://screenshotrun.com/api/v1/screenshots", {
  method: "POST",
  headers: {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://fixheaders.com/admin",
    cookies: [
      {
        name: cookie.name,
        value: cookie.value,
        domain: "fixheaders.com",
      },
    ],
  }),
});

The login endpoint depends on your app. Laravel's default route is POST /login with email and password fields (plus a CSRF token, more on that below). Django uses POST /accounts/login/. WordPress uses POST /wp-login.php with log and pwd fields.

The CSRF token problem

Most frameworks protect login forms with CSRF tokens. If you just POST to /login without a valid token, you'll get a 419 (Laravel) or 403 (Django/Rails). You need to first GET the login page, extract the CSRF token from the HTML or cookies, then include it in the POST request.

In Laravel, the CSRF token lives in a cookie called XSRF-TOKEN (URL-encoded) and needs to be sent back as an X-XSRF-TOKEN header or as a _token form field:

async function laravelLogin(baseUrl, email, password) {
  // Step 1: GET the login page to grab the CSRF cookie
  const loginPage = await fetch(`${baseUrl}/login`);
  const csrfCookie = loginPage.headers
    .get("set-cookie")
    ?.match(/XSRF-TOKEN=([^;]+)/)?.[1];

  if (!csrfCookie) {
    throw new Error("Could not extract CSRF token");
  }

  const csrfToken = decodeURIComponent(csrfCookie);

  // Step 2: POST login credentials with the CSRF token
  const response = await fetch(`${baseUrl}/login`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-XSRF-TOKEN": csrfToken,
      Cookie: `XSRF-TOKEN=${csrfCookie}`,
    },
    body: JSON.stringify({ email, password }),
    redirect: "manual",
  });

  // Step 3: extract the session cookie from the response
  const sessionCookie = response.headers
    .get("set-cookie")
    ?.match(/(\w+[-_]session)=([^;]+)/);

  if (!sessionCookie) {
    throw new Error("Login failed — no session cookie returned");
  }

  return { name: sessionCookie[1], value: sessionCookie[2] };
}

This is more involved than just copying a cookie from DevTools. But it runs unattended, and the session is always fresh. I use a similar approach inside screenshotrun's own renderer when I need to test authenticated pages during development.

When to use which method

Cookies — for any standard web app with form-based login. This is the most common case: admin panels, dashboards, CMS backends, SaaS tools. If you log in through a form in your browser and the site remembers you via a cookie, this is your method.

Custom headers — for internal tools and API-protected pages. If the page checks for an X-Auth-Token, a Bearer token, or any non-standard header, use the headers parameter. This also works for API documentation portals that require authentication headers.

Basic Auth — for staging environments and htpasswd-protected sites. If the browser shows a native username/password dialog (not an HTML form), the site uses HTTP Basic Authentication. Pass the credentials as a Base64-encoded Authorization header.

Some setups combine multiple methods. A staging server might have Basic Auth at the Nginx level and cookie-based sessions at the application level. In that case, pass both — the headers parameter with the Basic Auth header and the cookies parameter with the session cookie. The screenshotrun API sends everything together with the request.

Security notes

Don't hardcode credentials. Use environment variables or a secrets manager. If you're storing session cookies or passwords in your codebase, you're one accidental commit away from leaking them.

Use dedicated accounts. If you're automating dashboard screenshots, create a read-only user account specifically for this purpose. Don't use your admin credentials in scripts.

Be careful with screenshot storage. Authenticated dashboards might contain sensitive data: revenue numbers, user emails, internal metrics. If you're using screenshot caching or storing images long-term, think about who has access to those files.

Session cookies are temporary credentials. Treat them like passwords. Don't log them, don't put them in URLs, don't send them over unencrypted connections.

What I ended up doing with fixheaders

Back to the original problem. I needed to periodically check fixheaders.com scan stats without logging in manually every time.

Here's what I built: a scheduled task in Laravel (schedule:run) that fires every hour. It logs into fixheaders using the automated approach above, takes a screenshot of the dashboard, and saves it. I can open the latest screenshot any time and see the numbers without any extra steps.

Could I have built a proper API integration instead? Sure. But that would have taken way longer than the 20 minutes this approach took. Sometimes a screenshot is the fastest way to pull data out of a system that doesn't have an API for what you need.

If you want to try screenshotrun for something like this, the free plan gives you 200 screenshots per month, more than enough for hourly dashboard captures. The cookies and headers parameters are available on the Pro plan and above.

I hope this saves you some time next time you need to screenshot a page behind a login. If you hit edge cases with specific frameworks (NextAuth, Passport, Sanctum — they all have their quirks), feel free to reach out and I'll try to help.

How to take a website screenshot with Python

Vitalii Holben — Mon, 30 Mar 2026 19:55:57 +0000

Intro

Today I want to walk you through a step-by-step guide on how to capture website screenshots using Python. At first I thought this would take me a good week to put together and test everything properly. Turned out to be much simpler than I expected, especially when using a third-party API. But more on that later.

Python gives you three solid options: Selenium, Playwright, and a screenshot API. Each one covers a different use case and has its own limits. In this guide I'll go through all three, show you working code you can run right now, and explain when each approach makes sense.

What you'll need

Before we start, make sure you have Python 3.8 or higher installed. Check your version:

python --version

If Python is in place, let's create a working directory and a virtual environment:

mkdir python-screenshots

cd python-screenshots

python -m venv venv

source venv/bin/activate  # Linux/macOS

  
  
  or venv\Scripts\activate on Windows

The virtual environment keeps your global packages clean. Now we can install libraries and write code.

Method 1: Selenium

Selenium is an old, battle-tested tool for browser automation. If you already use it for testing or scraping, adding screenshots to your existing code is the easiest path. No need to pull in a new dependency — just call one method.

Installation

pip install selenium webdriver-manager

The webdriver-manager package automatically downloads the right Chrome driver. Without it, you'd have to manually download chromedriver and keep its version in sync with your browser version. If you've ever tried doing that by hand, you know it's an adventure on its own.

Basic screenshot

Create a file called selenium_screenshot.py:

from selenium import webdriver


from selenium.webdriver.chrome.options import Options

from selenium.webdriver.chrome.service import Service

from webdriver_manager.chrome import ChromeDriverManager


  
  
  Set up headless mode so the browser doesn't open on screen


options = Options()

options.add_argument('--headless=new')

options.add_argument('--window-size=1280,800')


  
  
  Create a driver with automatic chromedriver installation


driver = webdriver.Chrome(

    service=Service(ChromeDriverManager().install()),

    options=options

)


  
  
  Open the page and take a screenshot


driver.get('https://dev.to&#039;)

driver.save_screenshot('dev_to.png')

print(f'Saved: dev_to.png')

driver.quit()

Run it:

python selenium_screenshot.py

The terminal shows Saved: dev_to.png, and the file appears in the sidebar on the left. Open it up — there's the DEV Community homepage, captured by the headless browser. The image is 1280x661 pixels, about 309 KB. Notice that Selenium only captured the visible part of the page — whatever fits in the browser window. Content below the fold didn't make it into the screenshot.

Screenshotting a specific element

Sometimes you don't need the whole page — just one particular block. Selenium can capture individual elements too:

from selenium import webdriver

from selenium.webdriver.chrome.options import Options

from selenium.webdriver.chrome.service import Service

from selenium.webdriver.common.by import By

from webdriver_manager.chrome import ChromeDriverManager

options = Options()

options.add_argument('--headless=new')

options.add_argument('--window-size=1280,800')

driver = webdriver.Chrome(

    service=Service(ChromeDriverManager().install()),

    options=options

)

driver.get('https://dev.to&#039;)


  
  
  Find the element by CSS selector and screenshot just that


header = driver.find_element(By.TAG_NAME, 'header')

header.screenshot('dev_to_header.png')

print('Saved: header.png')

driver.quit()

The result is a narrow strip spanning the full page width. Just the DEV Community navigation bar, nothing else. This comes in handy when you need to capture a signup form, a product card, or any other specific block on the page.

Where Selenium falls short

Selenium has one notable limitation — it can't do full-page screenshots out of the box. The save_screenshot() method only captures the viewport. There are workarounds involving JavaScript scrolling and image stitching, but they're tedious and unreliable. If you need a full-page screenshot, that's where Playwright comes in.

Method 2: Playwright

Playwright is a more modern alternative from Microsoft. It supports Chrome, Firefox, and Safari through a single API. For screenshots, it beats Selenium for one simple reason — it can do full-page captures by adding literally one line of code.

Installation

pip install playwright

playwright install chromium

The second command downloads Chromium. If you need Firefox or WebKit, you can specify playwright install firefox webkit. For screenshots, Chromium is more than enough.

Basic screenshot

File playwright_screenshot.py:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:

    browser = p.chromium.launch()

    page = browser.new_page(viewport={'width': 1280, 'height': 800})

page.goto(&#039;https://news.ycombinator.com&#039;)
page.screenshot(path=&#039;hackernews.png&#039;)

print(&#039;Saved: hackernews.png&#039;)
browser.close()</code></pre><p>Run it:</p><pre><code class="language-bash">python playwright_screenshot.py</code></pre><p><img src="https://screenshotrun.com/storage/blog-attachments/0z2WFKyi1rfotmXgs43tuzbb0PXJT6IlKnipeOxg.png" alt="Playwright screenshot of Hacker News — code in editor, result in VS Code preview, terminal output" data-id="blog-attachments/0z2WFKyi1rfotmXgs43tuzbb0PXJT6IlKnipeOxg.png"></p><p>You can see the whole process in the terminal: Playwright installed first, then the script ran and printed <code>Saved: hackernews.png</code>. The preview shows a screenshot of Hacker News — orange header, list of posts, everything just like in a browser. The code is noticeably more compact than Selenium — no fiddling with drivers and options. But the real advantage of Playwright is coming up next.</p><h3>Full-page screenshot</h3><p>This is what makes Playwright worth picking. One option, <code>full_page=True</code>, and you get a screenshot of the entire page from top to bottom:</p><pre><code class="language-python">from playwright.sync_api import sync_playwright


with sync_playwright() as p:

    browser = p.chromium.launch()

    page = browser.new_page(viewport={'width': 1280, 'height': 800})

page.goto(&#039;https://news.ycombinator.com&#039;)
page.screenshot(path=&#039;hackernews_full.png&#039;, full_page=True)

print(&#039;Full-page screenshot saved: hackernews_full.png&#039;)
browser.close()</code></pre><p><img src="https://screenshotrun.com/storage/blog-attachments/3jIEfY6kylRUeWj1dZ2MCl6y1CkCtbAv9WfIbABs.png" alt="Playwright full-page screenshot of Hacker News — complete page from top to bottom" data-id="blog-attachments/3jIEfY6kylRUeWj1dZ2MCl6y1CkCtbAv9WfIbABs.png"></p><p>The difference is obvious. A regular screenshot gets cut off at the viewport height, while the full-page version captures everything — all 30 posts plus the footer with the search bar. Try doing that in Selenium with a single line — you can&#039;t.</p><h3>Mobile viewport</h3><p>Let&#039;s say you need to see how a site looks on a phone. Playwright lets you emulate specific devices:</p><pre><code class="language-python">from playwright.sync_api import sync_playwright


with sync_playwright() as p:

    browser = p.chromium.launch()

# Emulate iPhone 14
iphone = p.devices[&#039;iPhone 14&#039;]
context = browser.new_context(**iphone)
page = context.new_page()

page.goto(&#039;https://news.ycombinator.com&#039;)
page.screenshot(path=&#039;hackernews_mobile.png&#039;)

print(&#039;Mobile screenshot saved: hackernews_mobile.png&#039;)
browser.close()</code></pre><p><img src="https://screenshotrun.com/storage/blog-attachments/p0m0VdCcCbqwezeVtoQda6NbDExiKsTte0RTAwoa.png" alt="Playwright mobile screenshot — Hacker News rendered as iPhone 14 viewport" data-id="blog-attachments/p0m0VdCcCbqwezeVtoQda6NbDExiKsTte0RTAwoa.png"></p><p>The screenshot shows Hacker News fully adapted to a mobile screen — posts stack in a single column, fonts are larger, navigation is rearranged. Full mobile emulation. Playwright knows the specs of dozens of devices: iPhone, Pixel, iPad, and others. No need to manually figure out viewport widths and user agents.</p><h3>Waiting for content to load</h3><p>Another common problem — the screenshot fires before the page has finished loading. This is especially painful with JavaScript-heavy pages. Playwright can wait for a specific element to appear:</p><pre><code class="language-python">from playwright.sync_api import sync_playwright


with sync_playwright() as p:

    browser = p.chromium.launch()

    page = browser.new_page(viewport={'width': 1280, 'height': 800})

page.goto(&#039;https://github.com/trending&#039;)
# Wait for the repository list to appear
page.wait_for_selector(&#039;article.Box-row&#039;)
page.screenshot(path=&#039;github_trending.png&#039;)

print(&#039;Screenshot GitHub Trending saved: github_trending.png&#039;)
browser.close()</code></pre><p><img src="https://screenshotrun.com/storage/blog-attachments/ZxpIF5MHmKqddDNVIhBVLFCS2FCuWIytxQao9wXJ.png" alt="Playwright screenshot of GitHub Trending page with wait_for_selector — repositories fully loaded" data-id="blog-attachments/ZxpIF5MHmKqddDNVIhBVLFCS2FCuWIytxQao9wXJ.png"></p><p>The screenshot shows the GitHub Trending page with the repository list fully loaded. You can see stars, forks, descriptions — all the content is there. Without <code>wait_for_selector</code> you might have gotten a half-empty page with just a spinner. With it, Playwright waits until the target content actually appears in the DOM, then takes the shot.</p><h2>Method 3: Screenshot API</h2><p>Selenium and Playwright work great on your local machine. But try running them on a server — that&#039;s a different story. Chrome needs to be installed, it pulls in dozens of dependencies, eats RAM, and crashes from time to time. On CI/CD it&#039;s a separate headache: Dockerfiles grow, builds slow down.</p><p>A screenshot API takes a different approach — you send an HTTP request with a URL, and get a ready screenshot back. No browsers on your side. All the rendering happens remotely.</p><h3>How it works</h3><p>I&#039;ll show this using <a target="_blank" rel="noopener noreferrer nofollow" href="https://screenshotrun.com">ScreenshotRun</a> — an API I built for exactly this kind of task. The free plan gives you 300 requests per month, which is enough to try it out and see if this approach works for you.</p><p>First, <a target="_blank" rel="noopener noreferrer nofollow" href="https://screenshotrun.com/register">sign up</a> and copy your API key from the dashboard.</p><h3>Basic request</h3><p>File <code>api_screenshot.py</code>:</p><pre><code class="language-python">import requests


API_KEY = 'your-api-key-here'

URL = 'https://producthunt.com&#039;

response = requests.get(

    'https://screenshotrun.com/api/v1/screenshots/capture&#039;,

    headers={

        'Authorization': f'Bearer {API_KEY}',

    },

    params={

        'url': URL,

        'format': 'png',

        'width': 1280,

        'height': 800,

        'response_type': 'image',

    },

    timeout=60,

)

if response.status_code == 200:

    with open('producthunt.png', 'wb') as f:

        f.write(response.content)

    print('Screenshot saved: producthunt.png')

else:

    print(f'Error: {response.status_code} — {response.text}')

Run it:

pip install requests

python api_screenshot.py

No Chromium, no driver. One HTTP request — one file. The requests library is already installed for most Python developers, so there's nothing extra to set up. Note the response_type: 'image' parameter — it tells the API to return the binary image directly, without a JSON wrapper. Also worth setting timeout=60, since rendering heavy pages can take a few seconds.

Full-page screenshot via API

For a full-page screenshot, add one parameter:

import requests

API_KEY = 'your-api-key-here'

response = requests.get(

    'https://screenshotrun.com/api/v1/screenshots/capture&#039;,

    headers={

        'Authorization': f'Bearer {API_KEY}',

    },

    params={

        'url': 'https://github.com/topics&#039;,

        'format': 'png',

        'width': 1280,

        'full_page': True,

        'response_type': 'image',

    },

    timeout=60,

)

if response.status_code == 200:

    with open('github_topics_full.png', 'wb') as f:

        f.write(response.content)

    print('Full-page screenshot saved: github_topics_full.png')

else:

    print(f'Error: {response.status_code}')

The API scrolls the page itself, waits for lazy-loaded images to appear, and assembles the full snapshot. You don't need to think about scroll logic or timeouts — all of that is handled on the service side.

Mobile screenshot via API

import requests

API_KEY = 'your-api-key-here'

response = requests.get(

    'https://screenshotrun.com/api/v1/screenshots/capture&#039;,

    headers={

        'Authorization': f'Bearer {API_KEY}',

    },

    params={

        'url': 'https://stripe.com&#039;,

        'format': 'png',

        'width': 390,

        'height': 844,

        'response_type': 'image',

    },

    timeout=60,

)

if response.status_code == 200:

    with open('stripe_mobile.png', 'wb') as f:

        f.write(response.content)

    print('Mobile screenshot saved: stripe_mobile.png')

else:

    print(f'Error: {response.status_code}')

Width 390 and height 844 match the iPhone 14 screen size. You can emulate any mobile viewport the same way — just change the width and height values.

Batch processing multiple URLs

This is where the API really shows its strength. Say you need to screenshot several websites in one go:

import requests

import os

API_KEY = 'your-api-key-here'

urls = [

    'https://github.com&#039;,

    'https://stackoverflow.com&#039;,

    'https://dev.to&#039;,

    'https://news.ycombinator.com&#039;,

    'https://producthunt.com&#039;,

]

os.makedirs('screenshots', exist_ok=True)

for url in urls:

    domain = url.split('//')[1].split('/')[0].replace('.', '_')

response = requests.get(
    &#039;https://screenshotrun.com/api/v1/screenshots/capture&#039;,
    headers={
        &#039;Authorization&#039;: f&#039;Bearer {API_KEY}&#039;,
    },
    params={
        &#039;url&#039;: url,
        &#039;format&#039;: &#039;png&#039;,
        &#039;width&#039;: 1280,
        &#039;height&#039;: 800,
        &#039;response_type&#039;: &#039;image&#039;,
    },
    timeout=60,
)

if response.status_code == 200:
    filepath = f&#039;screenshots/{domain}.png&#039;
    with open(filepath, &#039;wb&#039;) as f:
        f.write(response.content)
    print(f&#039;✓ {domain}&#039;)
else:
    print(f&#039;✗ {domain}: {response.status_code}&#039;)


print(f'\nReady screenshots/')

Checkmarks roll through the terminal: ✓ github_com, ✓ stackoverflow_com, ✓ dev_to... PNG files appear in the screenshots/ folder, one per site. You might notice one of the requests returned a 429 (rate limit). The free plan has a limit on concurrent requests. For production use, you can either upgrade to a paid plan or add a pause between requests with time.sleep(1).

Five sites, five files, 35 lines of code. With Selenium you'd have to launch and shut down the browser for each URL. With the API, each request is just a regular HTTP call — no different from calling any other REST API.

Selenium vs Playwright vs API — an honest comparison

I've tried all three approaches. Here's what I think.

Selenium

When it fits: you already have Selenium in your project for testing or scraping. Adding save_screenshot() to existing code takes one line. Installing Selenium just for screenshots isn't worth it.

Pros: the most mature tool out there, with a huge amount of documentation and examples online. Supports all major browsers: Chrome, Firefox, Safari, Edge. You can interact with the page before taking a screenshot — click buttons, fill forms, scroll. Works well with pytest for testing.

Cons: no full-page screenshots out of the box, only viewport. You need to keep chromedriver version in sync with the browser (webdriver-manager helps, but doesn't always solve this). Verbose code even for simple tasks. On a server without a GUI, you need to configure headless mode and install rendering dependencies.

Playwright

When it fits: you're writing a script from scratch and need full-page screenshots, mobile emulation, or smart waiting. For local work and CI/CD with moderate volume, it's the best choice.

Pros: full-page screenshots with a single line — full_page=True. Built-in mobile device emulation with a ready-made device database. Smart waiting — you can wait for a specific element, network idle, or a particular page state. Clean, compact API with less boilerplate compared to Selenium. Same API for Chromium, Firefox, and WebKit.

Cons: Chromium weighs about 400 MB and downloads on first install. Each running browser instance consumes 200-400 MB of RAM. On servers you still need system dependencies for rendering (fonts, libraries). For 100+ screenshots you need to think about parallelism and browser pools.

Screenshot API

When it fits: production, automation, server-side scripts. When you don't want to deal with browser installation and resource management. When you need stability and predictability.

Pros: zero dependencies on your side — just requests. Works on any platform that has an HTTP client: a server, a Lambda function, a Jupyter Notebook. Doesn't consume your server's RAM or CPU. Easy to scale — no difference between 1 screenshot and 1000. The API handles cookie banners, lazy loading, and JavaScript rendering on its own.

Cons: you depend on an external service — if the API is down, no screenshots. The free plan has limits (300 requests/month on ScreenshotRun). A small network delay — each request takes 3-10 seconds instead of 1-3 seconds locally. Paid plans for higher volumes start at $9/month. You can't interact with the page (click, log in) — it's screenshot by URL only.

Bottom line

For one-off screenshots on your own machine — Playwright. For integrating into an existing test infrastructure — Selenium. For server automation and batch processing — Screenshot API.

ScreenshotRun gives you 300 free requests per month — try it and decide for yourself.

Tips that will save you time

A few things I figured out in practice.

Waiting for page load. Pages with heavy JavaScript might not finish rendering by the time the screenshot fires. In Playwright, use wait_for_selector() to wait for a specific element, or wait_for_load_state('networkidle') to wait until all network requests have settled. With the API approach, this is handled on the service side — it waits for full load automatically.

Cookie banners and popups. They constantly cover content in screenshots. In Selenium and Playwright you can dismiss them via JavaScript injection: find the "Accept" button or the entire banner and remove it from the DOM. The ScreenshotRun API can block cookie banners automatically.

Server resources. Each Chrome instance consumes 200-400 MB of RAM. Ten parallel browsers — that's already 2-4 GB just for screenshots. By comparison, the API approach uses approximately 0 MB of your RAM, because rendering happens on someone else's server.

File format. PNG is for pixel-perfect images with no quality loss. JPEG is for when file size matters and you can sacrifice some detail. WebP strikes a good balance between size and quality, though not all image viewers support it yet.

Rate limits. If you're making batch requests through an API, add time.sleep(1) between calls. Most API services limit the number of requests per second, and without a pause some requests will return a 429 error.

So we've covered all three approaches to taking website screenshots with Python — from local libraries with full control to a third-party API with zero setup. I've laid out the pros and cons, provided code examples. All that's left is to try them and pick what works best for your use case.

5 Ways Developers Use Screenshot APIs (Beyond Simple Page Captures)

Vitalii Holben — Fri, 27 Mar 2026 13:00:00 +0000

When people hear "screenshot API," most of them picture a pretty straightforward task: send a URL, get back an image of the page. And that is the basic scenario, sure. But developers who've already integrated a screenshot API into their projects tend to use it for things you might not have considered at all.

In this article, I've put together five real scenarios where a screenshot API can save you hours of work and solve problems that are either difficult or expensive to handle any other way.

1. Automatic OG Image Generation

Open Graph images are those previews that pop up when you share a link on Slack, Twitter, LinkedIn, or WhatsApp. If a page doesn't have an OG image, the shared link looks bland and gets fewer clicks. I actually covered how to create Open Graph images both manually and automatically in a previous article, so feel free to check that out for more detail.

As I mentioned there, the core problem is that every page needs its own image. If you have a blog with 50 posts, that's 50 images you need to create and maintain. And if you're running a SaaS product with dynamic pages — user profiles, dashboards, reports — then creating OG images by hand isn't realistic at all.

In cases like these, a screenshot API makes the whole thing much simpler, and the workflow is very sequential: you build an HTML template with the design you want (title, logo, background), render it through the API, and get back a ready-made image at 1200×630 — exactly the size social networks recommend. The entire process is automatic, with images generated on the fly or on a schedule. I won't go into too much detail here since I covered the full breakdown in that earlier post.

2. Link Previews for Directories and Catalogs

If you're building a site directory, a marketplace, an aggregator, or really any product where users submit links to external resources, you need visual previews of those links. Without them, your catalog ends up looking like a boring list of URLs.

A screenshot API lets you automatically generate a thumbnail for every site that gets added. In practice, it works like this: a user pastes a URL, your backend fires off a request to the API, gets back an image, and displays it as a card. No manual work involved, and no need to ask users to upload screenshots on their own.

This approach is used by site directories, aggregators like Product Hunt, bookmarking tools, and even internal corporate portals where employees share useful resources. Now, you might say that AI image generators can quickly produce any image you need these days, but this is a different thing entirely. With a screenshot API, you send dynamic HTML and get back a preview image in the exact style and design you prepared — no hallucinations, no randomness, just precisely what you asked for. On top of that, it's significantly faster than working with an AI model to generate images one by one.

3. Visual Regression Testing During Deploys

This is probably one of the most practical scenarios for developers. The idea is simple: before each deploy, you take screenshots of your key pages, then take them again after the deploy and compare. If something broke visually, you catch it before your users do.

Without a screenshot API, this process requires running a headless browser on your CI/CD server, which adds a fair amount of complexity: you need to install Chromium, manage memory, handle timeouts. I actually wrote about this whole process in detail in my article on how to take a website screenshot with Node.js. A screenshot API strips away all that infrastructure — you just send an HTTP request and get back an image.

A typical pipeline looks something like this: your CI/CD triggers a script that captures screenshots of 10 to 20 key pages through the API, compares them pixel by pixel against the previous versions, and sends an alert to Slack if the difference exceeds a set threshold.

4. Archiving and Compliance

In certain industries — finance, legal, pharma — companies are required to keep a record of what their website looked like at a given point in time. This comes up during audits, legal disputes, and regulatory compliance checks.

A screenshot API lets you automatically take daily or weekly snapshots of the pages you need and save them with a timestamp. And then if a dispute ever comes up, you have visual proof of exactly what was published on the site on a specific date.

This same approach is also useful for marketing teams that deal with sponsored content. Advertisers regularly ask for proof that their placement went live, and an automated screenshot with a date and URL handles that without any manual effort on anyone's part.

5. Competitor Monitoring and Change Tracking

The last scenario is taking regular screenshots of competitor pages to track changes. This could be a pricing page, a homepage, an ad campaign landing page, or even search results for specific keywords.

Developers typically set up a cron job that once a day (or more often) captures screenshots of a list of URLs through the API and stores them. Over time, this builds up a visual history of changes that you can analyze — when a competitor updated their pricing, redesigned their site, or launched a new campaign.

Some go even further and add automated screenshot comparison: if the current snapshot differs from the previous one by more than a certain percentage, the system fires off a notification. That way, you find out about changes on competitor sites the same day, without having to check them manually. I'm actually planning to add this feature to our service in the future as well.

The Common Thread

If you look at all five scenarios, there's one idea running through them: a screenshot API turns visual information into data you can work with programmatically. Instead of opening a browser, manually taking a screenshot, and saving it somewhere, you send an HTTP request and get back an image that you can process, store, compare, or display to a user — all of it automatically.

And the more pages you need to handle, the more time it saves.

Screenshotrun API lets you capture screenshots of any web page with a single HTTP request. 200 free screenshots per month, Bearer authentication, full-page and viewport modes.

What Competitor Pages to Monitor and How Often to Take Screenshots

Vitalii Holben — Thu, 26 Mar 2026 13:00:00 +0000

Most companies understand that keeping an eye on competitors is important. But in practice, it usually goes something like this: once a month, someone opens a competitor's website, scrolls through the homepage, glances at a few other pages, decides nothing has really changed, and closes the tab. Then we're caught off guard when that same competitor launches a new feature, changes their pricing, or reworks their positioning entirely — and we find out about it last.

The problem isn't that people don't want to monitor competitors. More often, the real issue is simpler — it's unclear what exactly to monitor and how frequently. Tracking every single page is too time-consuming, if not impossible. But ignoring competitors altogether leads to exactly the kind of surprises we just described: a new feature appears on their site, and you had no idea it was coming. In this article, we'll go over the specific pages worth monitoring, recommend a checking frequency for each type, and look at how to automate the entire process so it runs with minimal effort on your part.

Start With Five Competitors, No More

The first mistake is trying to monitor everyone. You might have 20 competitors in your space, but only 3 to 5 of them actually affect your business. These are the companies targeting the same audience, operating in the same price range, and showing up in the same search results — the ones who are genuinely your direct competitors, not just other players in the market.

We recommend picking five primary or potential competitors. For each one, identify 5 to 10 key URLs on their site. That gives you roughly 25 to 50 pages total, which is a perfectly manageable volume for automated page monitoring.

The Pricing Page Is the Most Valuable One

If you can only monitor a single page on a competitor's site, make it the pricing page. Price changes are a direct signal of strategic decisions. If a competitor raises their prices, it usually means they feel confident about growth and aren't worried about losing customers over a price bump. On the other hand, if they drop prices, the picture is different — they may be fighting for market share or struggling with churn.

But it's not just about the numbers themselves. Pay attention to a few other things as well:

Plan structure. If they had three plans and now there are four, that's already worth thinking about. If they added an enterprise tier with a "contact us" label instead of a price, it signals a move toward larger customers.

Feature gating. Which features ended up in the free plan and which ones are behind a paywall? When features get moved between plans, it's usually a strong signal of where their priorities are shifting.

Presentation. Did they switch to "Starting at $9/mo" instead of showing exact figures? Did they make annual billing the default option? Every detail like this is typically the result of an A/B test or a deliberate strategic decision.

How often to monitor: We recommend about once a week. Prices don't change every day, but missing a change for two weeks means losing time and failing to draw the right conclusions for your own strategy.

The Homepage Is a Mirror of Positioning

The homepage is how a company wants to be perceived. Every change on it is a deliberate choice. A new headline means they've shifted their messaging. If they removed a section with client logos and replaced it with case studies, they're switching from social proof to proof of value.

Here's what to watch for on the homepage:

The hero section, or the very first screen of the site: the headline, subheadline, and CTA. When a competitor changes their main headline, it's always meaningful. It means someone was given a task and spent time finding a better way to phrase what the company does.

Social proof: client logos, numbers ("10,000+ teams"), testimonials. If a large company's logo appears on their site for the first time, it's a clear sign the competitor just closed a major deal.

Navigation: new menu items often signal the launch of new products or sections and point to the company expanding its overall concept.

As we mentioned above, the homepage should be monitored about once a week. It doesn't get updated very frequently, but when it does, the changes are almost always significant.

The Features Page and Changelog

If a competitor maintains a public changelog or a "What's New" page, it's a goldmine. You can literally see what their development team is working on and which features they consider important enough to announce.

The features page (/features, /product) is also useful but changes less often. When it does change, though, it's typically a major update — new integrations, new capabilities, or a complete rethink of the product lineup.

How often: the changelog should be checked about twice a week. The features page is fine at once every two weeks.

The Blog and Company News Feed

A competitor's blog or news feed reveals two things: what topics they're betting on (their SEO strategy) and how they talk to their audience (tone of voice, the pain points they're highlighting).

You don't need to monitor every individual post. It's enough to track the main blog page — /blog — and see what new posts appear, how often they're publishing, and what topics they cover.

If a competitor suddenly starts publishing three articles a week instead of one, it means they've hired a content team, they're investing in SEO, or it could even signal a traffic drop they're trying to compensate for. If their topics shift from how-to guides to case studies, they're moving from attracting traffic to converting it.

Career Pages

The next page that's definitely worth tracking at least twice a month is the careers page, because job listings are an underrated source of competitive intelligence. If a competitor is hiring five ML engineers, that tells a very different story than if they're looking for three enterprise sales reps. Open positions reveal strategic direction earlier than any press release.

Monitor /careers or /jobs. Screenshots are especially useful here because job listings appear and disappear, and without an archive you won't notice the pattern.

Why once every two weeks? Because job postings don't update that frequently, and a two-week interval is sufficient to track hiring trends over time.

Landing Pages for Specific Campaigns

If you know a competitor is running ad campaigns, it's worth monitoring their landing pages. These pages show which messages and offers are working (or being tested) to attract customers.

The tricky part is that landing pages often live on subdomains or at unpredictable URLs. But if you've found them, add them to your monitoring list.

How often: daily, as long as the campaign is active. Landing pages change frequently — A/B tests, different variants, updated offers.

Summary Table

Page Type	Example URL	Frequency	Why It Matters
Pricing	/pricing	Once a week	Direct signal of strategy
Homepage	/	Once a week	Positioning and messaging
Changelog	/changelog, /whats-new	Twice a week	Product development pace
Features	/features, /product	Every 2 weeks	Major updates
Blog	/blog	Once a week	SEO and content strategy
Careers	/careers, /jobs	Every 2 weeks	Strategic direction
Landing pages	Various	Daily	Marketing campaigns

For 5 competitors with 7 to 8 pages each, that's roughly 35 to 40 URLs. At an average frequency of once per week, you're looking at about 150 to 200 screenshots per month. That's a perfectly manageable volume for an automated tool.

Manual Monitoring Doesn't Work

You could try doing all of this by hand. Open each page, take a screenshot, save it in a folder with today's date. That approach works for a week, maybe two. Then you forget, skip a day, lose the thread.

The problem with manual monitoring isn't laziness — it's scale. Checking 40 URLs once a week means 40 tabs, 40 screenshots, 40 files to organize. And that's assuming you only have 5 competitors. On top of that, you still need to compare current screenshots with previous ones to actually spot the changes.

An automated screenshot tool solves all of these problems. You set up your URLs and schedule once, then simply review the results whenever it's convenient. And if the tool also highlights visual differences between screenshots, you can immediately see what changed without having to compare images side by side.

What to Do With the Data You Collect

Screenshots on their own are just images. The real value comes when you start analyzing patterns:

If a competitor changed their pricing page three times in a single quarter, they're likely testing their monetization model — probably because the current one isn't performing well.

If their homepage shifted from "for developers" to "for teams," the competitor is moving upmarket.

If the changelog gets updated once a week consistently, you're probably looking at a well-funded team with a regular release cycle.

If positions like "Head of Partnerships" and "Enterprise Account Executive" show up on their careers page, the competitor is gearing up for an enterprise push.

Once a month, it's worth spending 30 minutes going through your screenshot archive and noting the trends. It won't replace a deep competitive analysis, but it gives you a steady stream of signals that help you make decisions faster.

Snapshot Archive automatically captures screenshots of any web page on a schedule and highlights visual differences between snapshots. Set up competitor monitoring in 5 minutes — no code, no manual work.

How to Take a Website Screenshot with Node.js (Playwright, Puppeteer, API)

Vitalii Holben — Thu, 26 Mar 2026 12:00:00 +0000

Today I'll show you how to take a screenshot of a web page using Node.js. We'll go through actual implementation, look at what can go wrong, and figure out how to deal with it.

In this guide we'll cover three working approaches: Playwright, Puppeteer, and a screenshot API. We'll start with the simplest script and then step by step work our way up to full-page captures, custom viewport sizes, mobile emulation, and even try to get around cookie banners and lazy-loaded page elements. Fair warning: this guide is long, but it covers a lot of ground and you'll pick up some things you probably haven't seen before.

To keep things clear, we'll run scripts step by step, add features one at a time, and look at the output after each change. Let's get started.

Before we start

You need Node.js 18 or newer. Let's check:

node -v

If you see v18 or higher, you're good. Otherwise grab the latest LTS from nodejs.org. Here's what I've got at the moment:

Works for us. Now create the project folder:

mkdir screenshots
cd screenshots
npm init -y

Folder created, we're inside it. Let's move on.

Method 1: Playwright

Playwright is my go-to tool for browser automation. It's maintained by Microsoft, supports Chromium, Firefox, and WebKit out of the box, and the API is clean. Install it:

npm install playwright

This downloads Chromium, Firefox, and WebKit binaries. About 400-500 MB total. If you only need Chromium, you can save time:

npx playwright install chromium

Basic screenshot

Create a file called screenshot.js:

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://github.com');
  await page.screenshot({ path: 'github.png' });
  await browser.close();
  console.log('Ready. github.png');
})();

Run it:

node screenshot.js

A couple of seconds and it's done. An image file appears in the project directory. Let's open it:

We've got our first result: an image at 1280x720 pixels. That's Playwright's default viewport. The screenshot captured only what fits in this viewport, roughly the top part of the page. Where 720 pixels ended, the image got cut off.

Obviously that's not quite what we want, so let's keep going.

Full-page screenshot

Usually you need the entire page, not just what fits in the window. Let's fix that. We only need to change one line:

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://github.com');
  await page.screenshot({
    path: 'github-full.png',
    fullPage: true
  });
  await browser.close();
  console.log('Ready. github-full.png');
})();

Run it again with node screenshot.js and open the result:

The image is now much taller, from the header all the way down to the footer. Width stays the same (1280px), height is whatever the page needed.

One thing to keep in mind: Chromium has a hard limit on screenshot height of 16,384 pixels. If the page is longer than that, the content will start repeating. This is a browser limitation, not a Playwright bug. For very long pages you'll need to capture them in chunks. But we're getting decent results already. Let's keep going.

Custom viewport size

1280x720 might not work for you. Say you need a screenshot that looks like a 1920x1080 desktop monitor:

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage({
    viewport: { width: 1920, height: 1080 }
  });
  await page.goto('https://github.com');
  await page.screenshot({ path: 'github-1080p.png' });
  await browser.close();
})();

Run the script and open the result:

The page now renders at 1920px width. If the site has a max-width container of 1200px, you'll see whitespace on the sides, exactly like on a real monitor.

Mobile screenshot

Playwright has built-in device profiles. Each one sets the viewport, user agent, pixel density, and touch support:

const { chromium, devices } = require('playwright');
const iPhone = devices['iPhone 14'];

(async () => {
  const browser = await chromium.launch();
  const context = await browser.newContext({
    ...iPhone
  });
  const page = await context.newPage();
  await page.goto('https://github.com');
  await page.screenshot({ path: 'github-mobile.png' });
  await browser.close();
})();

The page looks like you'd see it on an actual phone: hamburger menu instead of the navigation bar, mobile layout, touch-friendly spacing. The dimensions match the iPhone viewport (390x844 at 3x device pixel ratio).

Waiting for content to load

This is where a lot of people get tripped up. You run the script, get a screenshot, and half the page is blank. Images didn't load, dynamic content didn't render, there's a spinner in the middle of the screen.

The problem is that page.goto() by default waits for the load event. It fires when the HTML and its resources are loaded. But it says nothing about JavaScript that runs after load, lazy images, or data fetched from APIs.

The most reliable option for screenshots is networkidle:

await page.goto('https://example.com', {
  waitUntil: 'networkidle'
});

With this setting, it waits until there are no network requests for 500ms. Yes, it slows things down, but you get practically all the dynamic content in the output.

It gets even better though. If you know exactly what you're waiting for, you can specify it in the code:

// Wait for a specific element to appear
await page.goto('https://example.com');
await page.waitForSelector('.main-content');
await page.screenshot({ path: 'screenshot.png' });

Or just add a delay (not ideal, but sometimes necessary):

await page.goto('https://example.com');
await page.waitForTimeout(3000); // wait 3 seconds
await page.screenshot({ path: 'screenshot.png' });

Working with different formats: JPEG and PDF

By default screenshots are saved as PNG. But sometimes you need a different format. If file size matters, JPEG can be 3-5x smaller:

await page.screenshot({
  path: 'screenshot.jpg',
  type: 'jpeg',
  quality: 80
});

Or even PDF:

await page.pdf({
  path: 'page.pdf',
  format: 'A4'
});

Worth mentioning: PDF only works with Chromium. Firefox and WebKit in Playwright don't support it.

Method 2: Puppeteer

Puppeteer is the other popular option. It's maintained by Google, works with Chrome and Chromium. The API is very similar to Playwright, because Playwright was originally built by the same people who created Puppeteer.

npm install puppeteer

Downloads Chromium (about 170 MB). If you already have Chrome installed:

npm install puppeteer-core

Then you point it to the binary manually.

Basic screenshot

Same pattern, let's try making a basic screenshot:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://github.com');
  await page.screenshot({ path: 'github-puppeteer.png' });
  await browser.close();
})();

Puppeteer's default viewport is 800x600. That's narrower than Playwright's 1280x720. This catches some people off guard: the screenshot comes out narrow and the layout might switch to a tablet or even mobile breakpoint.

Just like in Playwright, you can set the size manually:

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setViewport({ width: 1280, height: 720 });
await page.goto('https://github.com');
await page.screenshot({ path: 'github-puppeteer.png' });
await browser.close();

Full-page screenshot

await page.screenshot({
  path: 'github-full-puppeteer.png',
  fullPage: true
});

Same fullPage: true flag. Same 16,384 pixel height limit.

Dealing with cookie banners

These days pretty much every European website shows a GDPR banner, because the law requires it. Neither Playwright nor Puppeteer can block them out of the box, but there are two workarounds:

Option 1: Click the banner before taking the screenshot.

await page.goto('https://example.com', { waitUntil: 'networkidle0' });

// Try clicking "Accept" if the banner exists
try {
  await page.click('[class*="cookie"] button', { timeout: 3000 });
  await page.waitForTimeout(1000);
} catch (e) {
  // No banner found, that's fine
}

await page.screenshot({ path: 'clean.png' });

This is pretty unreliable. Every site has its own banner, its own selectors, its own button text.

Option 2: Hide the banner with CSS.

await page.goto('https://example.com', { waitUntil: 'networkidle0' });

await page.addStyleTag({
  content: `
    [class*="cookie-banner"],
    [class*="consent"],
    [id*="cookie"],
    .cc-window,
    #onetrust-banner-sdk {
      display: none !important;
    }
  `
});

await page.screenshot({ path: 'no-banner.png' });

The trouble with this approach is that you'll keep adding new selectors as you hit new sites. And the banners themselves change over time, so the selectors you're clicking also change. It's a task that sounds simple but turns into endless maintenance at scale. Honestly, there's no clean solution yet beyond specifying which button selector to click to close the banner window.

Playwright or Puppeteer: which one to pick?

If you're starting from scratch, I'd go with Playwright.

Playwright supports three browser engines (Chromium, Firefox, WebKit). Puppeteer only does Chromium. Playwright has smarter auto-waiting, so you spend less time looking for the right screenshot delay to let all dynamic or animated elements load. Device emulation is built into both, and both keep it up to date.

Puppeteer works fine too. If you've already got a working Puppeteer setup, there's no reason to rewrite it. The screenshot API between the two is nearly identical. But for a new project, Playwright gives you more out of the box.

Real problems in production

So we know how to take screenshots. At first glance it doesn't seem that hard. But here's what happens when you move from "ran a script on my laptop" to "500 screenshots a day on a server".

Memory. Each Chromium instance eats 200-400 MB of RAM. 10 screenshots in parallel means 2-4 GB just for the browsers. Like any Node.js process, it will eventually crash with OOM, especially if you don't manage instances manually, don't reuse pages, and don't set up a queue.

Timeouts. Some pages take 15 seconds to load. Some will never finish loading because of an infinite spinner or a broken third-party script. You need timeout handling, retry logic, and realistically you'll never get it fully debugged.

Fonts. Headless Chromium on a Linux server doesn't have the same fonts as your Mac. Screenshots in production will look different. You need to install font packages (at minimum fonts-liberation, fonts-noto-cjk for CJK support) or use a Docker image that has them preinstalled.

Cookie banners, popups, chat widgets. We covered this above. Solvable for a single site, but across hundreds of different sites it becomes a job in itself.

These aren't theoretical problems. I ran into every one of them while building Screenshotrun. The screenshot rendering itself is the easy part. Everything around it is where the complexity lives.

Method 3: Screenshot API

If you don't want to deal with Chromium instances, fonts, queues, and cookie banner hacks, a screenshot API handles all of that for you. You send an HTTP request with a URL, you get an image back.

Here's how it looks with Screenshotrun. One HTTP call:

const https = require('https');
const fs = require('fs');

const apiKey = 'YOUR_API_KEY';
const url = encodeURIComponent('https://github.com');

const requestUrl =
  `https://screenshotrun.com/api/v1/screenshots/capture?url=${url}&response_type=image`;

const options = {
  headers: { Authorization: `Bearer ${apiKey}` },
};

https.get(requestUrl, options, (res) => {
  const chunks = [];
  res.on('data', (chunk) => chunks.push(chunk));
  res.on('end', () => {
    fs.writeFileSync('github-api.png', Buffer.concat(chunks));
    console.log('Ready. github-api.png');
  });
});

Just don't forget to put in your own API key, which you can get for free, along with 300 screenshots per month.

Run it and open the file:

Clean screenshot. No Chromium download, no font issues, no memory management. The API handles cookie banners on its own, waits for dynamic content to load, and returns a ready-to-use image.

Using fetch (Node.js 18+)

If you prefer the fetch API that ships with Node.js 18:

const fs = require('fs');

const apiKey = 'YOUR_API_KEY';
const targetUrl = encodeURIComponent('https://github.com');

async function takeScreenshot() {
  const response = await fetch(
    `https://screenshotrun.com/api/v1/screenshots/capture?url=${targetUrl}&response_type=image`,
    {
      headers: { Authorization: `Bearer ${apiKey}` },
    }
  );
  const buffer = Buffer.from(await response.arrayBuffer());
  fs.writeFileSync('github-fetch.png', buffer);
  console.log('Ready. github-fetch.png');
}

takeScreenshot();

Custom size and format

Pass parameters in the query string:

const fs = require('fs');

const params = new URLSearchParams({
  url: 'https://github.com',
  width: '1920',
  height: '1080',
  format: 'webp',
  full_page: 'true',
  response_type: 'image'
});

async function takeScreenshot() {
  const response = await fetch(
    `https://screenshotrun.com/api/v1/screenshots/capture?${params}`,
    {
      headers: { Authorization: 'Bearer YOUR_API_KEY' },
    }
  );
  const buffer = Buffer.from(await response.arrayBuffer());
  fs.writeFileSync('github-full.webp', buffer);
}

takeScreenshot();

You get a full-page WebP screenshot at 1920px wide. The API does all the work: launches a browser, waits for the page to load, scrolls through to trigger lazy images, captures the result, and sends it back.

Mobile screenshots via API

const fs = require('fs');

const params = new URLSearchParams({
  url: 'https://github.com',
  width: '390',
  height: '844',
  device: 'mobile',
  response_type: 'image'
});

async function takeScreenshot() {
  const response = await fetch(
    `https://screenshotrun.com/api/v1/screenshots/capture?${params}`,
    {
      headers: { Authorization: 'Bearer YOUR_API_KEY' },
    }
  );
  const buffer = Buffer.from(await response.arrayBuffer());
  fs.writeFileSync('github-mobile-api.png', buffer);
}

takeScreenshot();

No need to maintain a device list or configure user agents. Just pass the dimensions.

When to use what

Playwright or Puppeteer if you need screenshots occasionally, everything runs locally, and you're willing to maintain the infrastructure. Good for testing, one-off tasks, or when you need full browser control (clicking through forms, filling fields, interacting with the page before capturing).

Screenshot API if screenshots are part of your product, you need them at scale, or you just don't want to deal with headless browser infrastructure. You trade some flexibility for zero maintenance.

There's no universal answer. In my own projects I use Playwright in development and testing, and the API in production where reliability and speed matter more than saving a few cents per request.

Comparison

	Playwright	Puppeteer	Screenshot API
Install size	~400 MB	~170 MB	0 (HTTP request)
Browsers	Chromium, Firefox, WebKit	Chromium only	Managed for you
Default viewport	1280x720	800x600	1280x720 (configurable)
Full-page capture	Yes	Yes	Yes
Cookie banners	Manual	Manual	Automatic
Fonts on Linux	Install yourself	Install yourself	Handled
Scaling to 1000+/day	Your infrastructure	Your infrastructure	Handled
Cost	Free (+ server costs)	Free (+ server costs)	Free tier, then paid

Try Screenshotrun

If you want to try the API approach, Screenshotrun gives you 300 free screenshots per month. No credit card, no setup. Sign up, grab your API key from the dashboard, and paste it into any of the code examples above.

The API also supports WebP output, dark mode, ad blocking, custom CSS injection, and webhooks for async rendering. Full documentation here.

How to Take a Website Screenshot with PHP

Vitalii Holben — Wed, 25 Mar 2026 00:15:06 +0000

I want to walk you through the full process of taking website screenshots from PHP today. Not theory, not a library overview -- the actual thing. Open a terminal, install dependencies, write code, run it, get a PNG file with a screenshot. The whole path from an empty folder to a working result.

Why would you even need this? Link previews for a directory site, automated OG images, screenshots for client reports, visual monitoring. Sooner or later a PHP project needs to turn a URL into an image.

The problem is that PHP can't render web pages on its own. There's no browser engine built in. So we'll need a helper -- headless Chrome through Puppeteer. It's a Node.js package, and yes, that means we need Node alongside PHP. Sounds like overkill, but you'll see it's not that bad.

Let's try it.

Installing Node.js

First things first -- we need Node.js. Puppeteer won't run without it.

If you're on macOS with Homebrew, one command:

brew install node

On Ubuntu it's a bit longer:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

Quick check that everything installed:

node -v
npm -v

See version numbers? Good, moving on.

Creating the project and installing Puppeteer

Now we need a separate folder for our screenshot tool. I usually put it next to the PHP project, but it doesn't really matter where.

mkdir screenshot-tool
cd screenshot-tool
npm init -y
npm install puppeteer

This will take a minute. Puppeteer downloads a full Chromium binary during installation -- somewhere between 170 and 400 megabytes depending on your OS. Yeah, it's a chunky package. That's the price of getting a real browser you can control from code.

If you're on Ubuntu, Chrome might fail to launch the first time -- it needs system libraries that aren't there on a fresh install:

sudo apt-get install -y libnss3 libatk1.0-0 libatk-bridge2.0-0 \
    libcups2 libdrm2 libxkbcommon0 libxcomposite1 libxdamage1 \
    libxrandr2 libgbm1 libpango-1.0-0 libcairo2 libasound2

On macOS you can skip this step -- everything works out of the box.

Writing the screenshot script

Now for the fun part. Create a file called screenshot.js inside the screenshot-tool folder:

const puppeteer = require('puppeteer');

const url = process.argv[2];
const output = process.argv[3] || 'screenshot.png';

if (!url) {
    console.error('Usage: node screenshot.js <url> [output-file]');
    process.exit(1);
}

(async () => {
    const browser = await puppeteer.launch({
        headless: 'new',
        args: ['--no-sandbox', '--disable-setuid-sandbox'],
    });

    const page = await browser.newPage();
    await page.setViewport({ width: 1280, height: 800 });

    await page.goto(url, {
        waitUntil: 'networkidle2',
        timeout: 30000,
    });

    await page.screenshot({ path: output, fullPage: false });
    await browser.close();

    console.log(output);
})();

What this does: takes a URL from the command line arguments, launches headless Chrome, opens the page, waits for it to load, takes a screenshot, saves it to a file. Then closes the browser.

Let's test it right away:

node screenshot.js https://screenshotrun.com test.png

If everything worked, you'll see a new test.png file in the folder. Open it -- if you see a screenshot of the page, the script works.

Connecting it to PHP

The script works from the terminal. Now we need PHP to call it. The idea is simple: PHP runs our Node script through shell_exec() like any other console command, and picks up the resulting PNG from disk.

<?php

$url = 'https://screenshotrun.com';
$outputDir = __DIR__ . '/screenshots';
$filename = md5($url) . '.png';
$outputFile = $outputDir . '/' . $filename;

$scriptPath = __DIR__ . '/../screenshot-tool/screenshot.js';

$command = sprintf(
    'node %s %s %s 2>&1',
    escapeshellarg($scriptPath),
    escapeshellarg($url),
    escapeshellarg($outputFile)
);

echo "Running: {$command}\n";

$output = shell_exec($command);

if (file_exists($outputFile)) {
    echo "Done! Saved to: {$outputFile}\n";
    echo "File size: " . round(filesize($outputFile) / 1024) . " KB\n";
} else {
    echo "Something went wrong.\n";
    echo "Output: {$output}\n";
}

Note the 2>&1 at the end of the command -- it redirects stderr to stdout. Without it, if Node throws an error, PHP simply won't see it and you'll be left guessing why nothing works.

Adding options

The basic version works, but let's make it more useful. Here's a wrapper function with viewport size and full-page support:

<?php

function takeScreenshot(
    string $url,
    string $outputDir,
    int $width = 1280,
    int $height = 800,
    bool $fullPage = false
): ?string {
    $filename = md5($url . $width . $height . ($fullPage ? '1' : '0')) . '.png';
    $outputFile = rtrim($outputDir, '/') . '/' . $filename;

    $scriptPath = __DIR__ . '/../screenshot-tool/screenshot.js';

    $command = sprintf(
        'node %s %s %s %d %d %s 2>&1',
        escapeshellarg($scriptPath),
        escapeshellarg($url),
        escapeshellarg($outputFile),
        $width,
        $height,
        $fullPage ? 'true' : 'false'
    );

    shell_exec($command);

    return file_exists($outputFile) ? $outputFile : null;
}

// Desktop screenshot
$file = takeScreenshot('https://screenshotrun.com', __DIR__ . '/screenshots');
echo $file ? "Desktop: {$file}\n" : "Failed\n";

// Mobile (iPhone-sized)
$file = takeScreenshot('https://screenshotrun.com', __DIR__ . '/screenshots', 375, 812);
echo $file ? "Mobile: {$file}\n" : "Failed\n";

// Full page with scrolling
$file = takeScreenshot('https://screenshotrun.com', __DIR__ . '/screenshots', 1280, 800, true);
echo $file ? "Full page: {$file}\n" : "Failed\n";

Now you can take desktop, mobile, and full-page screenshots with one function call.

There's a simpler way

We went through the whole thing: Node.js, Puppeteer with Chromium, a JS script, shell_exec from PHP, a wrapper with options. It works -- but it's a lot of moving parts for one task.

You can get the same result with a single HTTP request. No Node.js, no Chromium, no two scripts in two languages:

<?php

$apiKey = 'YOUR_API_KEY';

$ch = curl_init('https://screenshotrun.com/api/v1/screenshots');
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_HTTPHEADER     => [
        'Authorization: Bearer ' . $apiKey,
        'Content-Type: application/json',
    ],
    CURLOPT_POSTFIELDS     => json_encode([
        'url'           => 'https://screenshotrun.com',
        'format'        => 'png',
        'block_cookies' => true,
    ]),
    CURLOPT_RETURNTRANSFER => true,
]);

$response = json_decode(curl_exec($ch), true);
curl_close($ch);

echo "Screenshot ID: " . $response['data']['id'];

I built ScreenshotRun as a simpler alternative — one HTTP request instead of managing Puppeteer. Free tier gives you 300 screenshots/month.

If you're using AI coding tools like Claude or Cursor, there's also an MCP server that lets your AI agent take screenshots directly.