DEV Community: Grabbit

How to Screenshot a List of URLs (Bulk Capture for Research and Audits)

Nico Acosta — Tue, 07 Jul 2026 11:40:47 +0000

You have a spreadsheet, a sitemap, or a list of competitor pages, and you need a screenshot of each one. Doing it by hand means opening twenty tabs and pressing the capture key twenty times. This guide covers every method that actually works, from a free browser extension for a one-off batch to a scripted loop you can run on a schedule.

The short answer

To screenshot a list of URLs, loop over the list and capture each URL once. There is no magic "capture them all in one shot" primitive. Every tool, extension, or API does the same thing under the hood: it visits each page in turn and renders it. The real choice is how you drive that loop:

One-off, a handful of URLs: a browser extension that reads a pasted list.
Repeatable, or part of a pipeline: a short script that calls a screenshot API once per URL.
You already write capture code: keep your headless browser, just point the loop at a managed renderer if local Chromium is flaky in CI.

Method 1: a browser extension (for a quick one-off)

If you just need to grab a dozen pages once and never again, a Chrome extension like Multiple Screenshots is the fastest path. You paste your list, it opens each page, captures it, and saves the files locally. No code.

The limits show up the moment the job repeats. Extensions run in your browser, on your machine, with your session. You cannot put that in CI, schedule it overnight, or hand it to a teammate as a reproducible step. For a true one-time audit, fine. For anything you will do again, it is a dead end.

Method 2: an open-source script (DIY headless)

The classic developer answer is a script that drives a headless browser over the list. Tools like webscreenshot or a few lines of Puppeteer read a file of URLs and capture each one:

import puppeteer from 'puppeteer';
import { readFileSync } from 'node:fs';

const urls = readFileSync('urls.txt', 'utf8').trim().split('\n');
const browser = await puppeteer.launch();
const page = await browser.newPage();

for (const url of urls) {
  await page.goto(url, { waitUntil: 'networkidle2' });
  await page.screenshot({ path: `out/${encodeURIComponent(url)}.png`, fullPage: true });
}

await browser.close();

This works, and it is free. What it does not solve is everything around the capture: keeping Chromium installed and patched, handling pages that block headless browsers, dealing with cookie banners, and surviving in a CI runner or serverless function where a real browser binary is awkward to ship. Those problems scale with the size of your list. See screenshot a website from a URL for a fuller comparison of the DIY path versus an API.

Method 3: a screenshot API in a loop (repeatable)

When the job has to run more than once, a screenshot API turns each capture into a single HTTP request, so the loop is the whole program. You send a URL, you get back a hosted image. No browser to install, nothing to keep patched.

Here is the full pattern in Node. Read the list, capture each URL, and collect the hosted image URLs:

const urls = ['https://example.com', 'https://stripe.com', 'https://vercel.com'];
const results = [];

for (const url of urls) {
  const res = await fetch('https://api.grabbit.live/v1/grabs', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer sk_live_...',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ url, width: 1280, full_page: true, format: 'webp' }),
  });
  const data = await res.json();
  results.push({ url, image_url: data.image_url });
}

console.table(results);

Each response includes a hosted image_url, so you can drop the results straight into a CSV, a database, or a dashboard. Because every request is independent, you can keep the loop sequential for simplicity, or add limited concurrency if you want the batch to finish faster. This is exactly the kind of repeatable, scriptable job Grabbit's automated screenshots are built for, and you can wire it up with a free test key before adding a card.

A note on honesty: Grabbit does not expose a single "send me an array of URLs" endpoint. One request captures one URL. The loop above is the bulk pattern, and it keeps each capture independent so one bad URL never sinks the whole batch.

Choosing per-URL options

Each call in the loop is configured on its own, so a mixed list is no problem. The parameters that matter for a bulk job:

full_page: true captures the entire scrollable page, not just the viewport. Essential for audits where you want the whole page on record.
width sets the viewport (320 to 1920). Use a consistent width across the list so the screenshots line up for comparison.
format can be png, jpeg, or webp. WebP keeps a large batch small on disk.
delay_ms waits up to 10 seconds before the capture, which helps on pages that fade content in after load.

For a large list where you do not want to hold the connection open per request, the same endpoint accepts Prefer: respond-async (or ?async=true) and returns immediately with a job you poll later. That keeps a thousand-URL run from blocking your script.

Bulk screenshots for audits and monitoring

The reason most people want to screenshot a list of URLs is not the screenshots themselves, it is the comparison. Capture your competitors' landing pages today, capture them again next month, and the diff tells a story. Save each image_url next to its source URL and a timestamp, and you have the raw material for website change monitoring without building a crawler from scratch.

The same loop powers a few common jobs:

SEO audits: snapshot every page in a sitemap to spot rendering or layout regressions.
Competitor tracking: re-run the same list on a schedule and compare.
QA evidence: capture key pages on every deploy and attach them to the release.

Wrapping up

Screenshotting a list of URLs always comes down to a loop. A browser extension covers a one-time batch; a DIY script works until local Chromium becomes the maintenance burden; a screenshot API turns the whole job into a few lines that run anywhere, including CI and serverless. Point the loop at your list, collect the hosted image URLs, and you have a repeatable bulk-capture pipeline. To automate it end to end, see Grabbit's automated screenshots.

Originally published on the Grabbit blog.

Screenshots for AI Agents: Giving Your LLM Eyes on the Web

Nico Acosta — Mon, 06 Jul 2026 11:39:03 +0000

Most LLMs process text. But a growing category of agent tasks is fundamentally visual: checking whether a deploy broke a page layout, verifying that an OG card looks right before a post goes live, monitoring a competitor's pricing page for changes. Text cannot do these jobs. A screenshot can.

The pattern is straightforward: capture a screenshot via API, get back a hosted image URL, pass that URL to a vision model. No headless browser to manage, no Puppeteer session to keep alive, no parsing fragile DOM trees.

Why text-only agents hit a wall

HTML is a poor proxy for what a user sees. Dynamic frameworks render client-side; the raw HTML is a template with no content. CSS controls what is visible and what is not. Interstitials, cookie banners, and lazy-loaded images change the actual visual state. A text-based agent scraping HTML sees none of this.

Vision models bypass the problem entirely. They look at the page the way a user does. The prerequisite: they need an image to analyze. That is what the screenshot API provides.

The capture-and-analyze pattern

The core loop for a vision-capable agent:

async function seeUrl(url: string): Promise<string> {
  const res = await fetch('https://api.grabbit.live/v1/grabs', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.GRABBIT_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      url,
      width: 1280,
      height: 720,
      format: 'webp',
    }),
  });

  const grab = await res.json();
  return grab.image_url; // a hosted URL, ready to pass to any vision model
}

The function returns a URL your agent passes directly to whatever vision model it uses as an image input. The image is already hosted; the vision model fetches it. No base64 encoding, no file handling.

Capture params that matter for agents

Three params make the most difference in agentic contexts.

selector waits for a specific element to appear in the DOM, then captures just that element. Useful when you care about one component, not the whole page.

{
  "url": "https://yoursite.com/dashboard",
  "width": 1280,
  "height": 720,
  "format": "webp",
  "selector": "#revenue-chart"
}

The API returns an image of the #revenue-chart element. Pass that to a vision model to read a number, detect a visual anomaly, or compare it to a previous capture.

full_page captures the entire document height, not just the initial viewport. Set this when your agent needs to see content that loads below the fold.

delay_ms adds a fixed wait after page load. If the page fetches data from an API and renders it into the DOM, a delay_ms of 500 to 1000 gives the script time to finish before the capture fires.

Agentic use cases

Automated visual QA. After each deploy, an agent screenshots key pages and passes them to a vision model with a prompt describing what to look for. The model spots a broken nav, a missing hero image, or an overlapping button before a human does.

OG card verification. Before a post goes live, an agent screenshots the /og?title=... route at 1200 by 630, passes the image to a vision model, and confirms the title, author, and brand logo are all present and not clipped. See How to Generate Dynamic OG Images from Any URL for the template pattern this builds on.

Monitoring competitor pages. Capture a competitor's pricing page on a schedule, then diff the image against the previous capture using a vision model. An alert fires when the layout or text changes significantly.

Visual data extraction. Some dashboards render data into charts with no accessible API. A screenshot of the chart, analyzed by a vision model, extracts the numbers without reverse-engineering a private API.

Registering the tool in an agent

The pattern is the same across frameworks: define a function tool that accepts a URL and returns the image_url.

const screenshotTool = {
  name: 'screenshot_url',
  description: 'Capture a screenshot of a web page and return a hosted image URL for visual analysis.',
  parameters: {
    type: 'object',
    properties: {
      url: {
        type: 'string',
        description: 'The page to screenshot.',
      },
      selector: {
        type: 'string',
        description: 'Optional CSS selector. Waits for this element and captures it.',
      },
      full_page: {
        type: 'boolean',
        description: 'Capture the full document height.',
      },
      delay_ms: {
        type: 'number',
        description: 'Milliseconds to wait after page load before capturing.',
      },
    },
    required: ['url'],
  },
};

When the agent framework calls this tool and the function returns image_url, include it in the next LLM message as an image block. The model sees the page and can reason about it.

From agent tool to MCP server

If you use an MCP-compatible host, you can expose screenshot capability as an MCP tool. The agent calls screenshot_url, gets back an image URL, and uses it in the next turn. Grabbit is designed for exactly this: one API key, one endpoint, no browser runtime to maintain.

Go further

For running this pattern on a full page set on a CI schedule, Visual Regression Testing: A Practical Guide covers the screenshot-and-compare approach in depth.

For capturing any URL on demand from your own code, see the Grabbit screenshot API.

Originally published on the Grabbit blog.

How to Take a Website Screenshot in Node.js (4 Ways)

Nico Acosta — Sun, 05 Jul 2026 11:37:11 +0000

Node.js has no shortage of ways to screenshot a website. The honest list is four: Puppeteer, Playwright, a thin wrapper like capture-website, or a hosted API. The first three all run Chromium on your server; the fourth does not. This guide shows each with working code and the trade-off that decides which one you want.

1. Puppeteer (the default)

Puppeteer is the most common choice and drives headless Chrome directly:

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle0' });
await page.screenshot({ path: 'example.png', fullPage: true });
await browser.close();

The detail that matters is waitUntil: 'networkidle0', which waits for the network to settle before capturing so you do not screenshot a half-loaded page. fullPage: true captures the whole scrolling page. For elements, quality, and the lazy-load gotchas, see full-page screenshots in Puppeteer.

2. Playwright (cross-browser)

Playwright has nearly identical code and adds Firefox and WebKit with one API:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'example.png', fullPage: true });
await browser.close();

The practical wins over Puppeteer are auto-waiting (less timing code) and being able to capture the same page in three engines, including the engine behind Safari. See screenshots in Playwright for the details.

3. capture-website (the short wrapper)

If you just want one screenshot and do not want to manage a browser lifecycle, capture-website wraps Puppeteer into one call:

import captureWebsite from 'capture-website';

await captureWebsite.file('https://example.com', 'example.png', {
  fullPage: true,
});

It still installs and runs Chromium under the hood, so the operational cost is the same as Puppeteer. It just hides the boilerplate. Avoid older packages like node-webshot that wrap the abandoned PhantomJS; do not build new code on them.

The cost the first three share

All three options above mean you run a browser on your server. None of the hard parts are the screenshot call:

Provisioning Chromium. It needs a long list of system libraries. Slim containers and serverless functions hit missing-dependency errors before the first capture.
Memory and zombie processes. A browser not closed on every error path leaks memory and orphans processes under load.
Patching and scaling. Chromium ships security updates constantly, and one browser handles one job at a time, so volume means a pool and a queue.

If screenshots are a production feature rather than a script, this is infrastructure you now own.

4. A hosted API (no browser to run)

A screenshot API runs the browser fleet for you. From Node.js it is one fetch:

const res = await fetch('https://api.grabbit.live/v1/grabs', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://example.com',
    width: 1280,
    full_page: true,
    format: 'webp',
  }),
});

const { image_url } = await res.json();

The response is a hosted image URL:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "format": "webp",
  "bytes": 48210,
  "execution_ms": 1180
}

The library options map onto request parameters: viewport is width (320 to 1920) and height (240 to 1080), full page is full_page, the element pattern is a selector field, and the manual wait becomes delay_ms (0 to 10000). format is png, jpeg, or webp.

Which to use

Already running Puppeteer or Playwright for tests or scraping: add the screenshot call, you are done.
A quick one-off script: capture-website is the least code.
Screenshots are a production feature: an API, so you do not operate Chromium in your Node service at all.

For the framework deep dives, see screenshots in Puppeteer and screenshots in Playwright. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing.

Originally published on the Grabbit blog.

Playwright Visual Regression Testing: Catch UI Bugs in CI

Nico Acosta — Sat, 04 Jul 2026 11:37:30 +0000

Playwright has visual regression testing built in. One assertion, toHaveScreenshot, captures the page, diffs it against a stored baseline, and fails the test when the UI changes unexpectedly. The setup is genuinely a few lines. The hard part is not the API; it is keeping baselines stable so CI catches real regressions instead of failing on font rendering. This guide covers both.

The core workflow: toHaveScreenshot

A visual test is a normal Playwright test with one screenshot assertion:

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

test('homepage looks correct', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('homepage.png');
});

On the first run, there is no baseline, so Playwright captures homepage.png and saves it, and the test "fails" once to tell you a baseline was created. On every run after that, it captures a fresh screenshot, compares it pixel by pixel against the saved baseline, and passes only if they match within your threshold.

toHaveScreenshot is the right assertion to reach for: it auto-waits for the page to stop changing and retries until the screenshot is stable, which removes a whole class of flaky-capture bugs. Prefer it over the older toMatchSnapshot.

Updating baselines after an intentional change

When you change the UI on purpose, the baseline is now wrong and the test should fail until you accept the new look. Regenerate baselines with a flag:

npx playwright test --update-snapshots

This rewrites the baseline images for any test whose capture changed. Commit those images so the new baseline travels with the code in Git, and reviewers can see the visual diff in the pull request.

The real problem: CI flake

The most common frustration is tests that pass locally and fail in CI. This is almost never a real regression. It is the rendering environment: a different OS, different fonts, a different GPU, or a different browser build produces sub-pixel anti-aliasing differences that fail an exact-match comparison.

Two fixes, used together:

1. Generate baselines in the CI environment. Do not commit baselines captured on your Mac and expect them to match a Linux CI runner. Generate them inside the same container that runs the tests, commonly the official Playwright Docker image, so the rendering matches.

2. Allow a small diff. Set a tolerance so anti-aliasing noise does not fail the build:

await expect(page).toHaveScreenshot('homepage.png', {
  maxDiffPixelRatio: 0.01, // tolerate up to 1% differing pixels
});

maxDiffPixelRatio and maxDiffPixels are the two knobs. Start strict and loosen only as far as you must to stop false failures, or you will mask real regressions.

Where a screenshot API fits

Playwright's toHaveScreenshot is the right tool for asserting your own components and pages inside a Playwright suite. A screenshot API is not a replacement for it; it is a complementary capture layer for a few specific jobs:

A stable, environment-independent baseline source. Capturing the same URL through a hosted browser fleet gives you a consistent render that does not depend on each developer's machine.
Capturing pages outside your test suite. Monitoring a live production page or a third-party page you do not control, on a schedule, is a capture job, not a Playwright test.
A reference image of the real deployed page to compare against, rather than a locally rendered one.

Here is a baseline capture as a single request:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "png"
  }'

The response includes a hosted image you can store as a reference:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....png",
  "width": 1280,
  "format": "png",
  "bytes": 96420,
  "execution_ms": 1240
}

Width accepts 320 to 1920, height 240 to 1080, full_page captures the whole page, and delay_ms (0 to 10000) lets content settle before the shot. To be clear about scope: Grabbit captures the images. The diffing, the assertions, and the pass/fail live in Playwright or your VRT tool of choice.

Putting it together

Use toHaveScreenshot for component and page assertions inside your Playwright suite.
Generate baselines in the CI container and allow a small maxDiffPixelRatio so you catch real regressions, not font noise.
Reach for a screenshot API when you need a consistent baseline source or to capture pages that live outside the test suite.

For the bigger picture, see the practical guide to visual regression testing and the roundup of visual regression testing tools. For Playwright screenshot mechanics beyond testing, see taking screenshots in Playwright.

Originally published on the Grabbit blog.

How to Screenshot an Entire Web Page on Any Device

Nico Acosta — Fri, 03 Jul 2026 11:38:47 +0000

Full-page screenshots are straightforward on desktop but awkward on mobile, and totally different again when you need them from code. This guide covers the real methods for each situation so you can pick the right one.

The quickest cross-device method

If you are writing code, running a CI job, or building a tool that needs to capture pages from a server or agent, a screenshot API is the only method that works everywhere. The browser runs in the cloud, not on your device.

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

Setting full_page: true tells the renderer to scroll to the bottom of the page and stitch all the sections into one image. The response contains a hosted image_url you can write directly to your database or pass to a front end. No browser install, no Puppeteer, no scrolling logic to maintain.

For a broader look at programmatic capture, see how to screenshot a website from a URL.

On desktop: Chrome DevTools

Chrome includes a full-page screenshot command that requires no extensions.

Open DevTools: F12 on Windows or Linux, Cmd + Opt + I on Mac.
Open the command palette: Ctrl + Shift + P on Windows, Cmd + Shift + P on Mac.
Type full size screenshot and press Enter.
Chrome saves a PNG of the full page to your Downloads folder.

The capture uses the same Chromium engine as most screenshot APIs, so the result looks accurate. The limitation is that it only works from a desktop browser and cannot be scripted. For more detail on this method, see how to capture a full-page screenshot in Chrome.

On desktop: Firefox

Firefox exposes its screenshot tool without DevTools.

Right-click anywhere on the page and choose Take Screenshot.
Click Save full page.
Firefox downloads a PNG of the entire scrollable page.

No keyboard shortcuts to remember and no extensions needed. The output is always PNG.

On Mac: Safari

Safari has no native full-page screenshot shortcut. Your options are:

Use Chrome on the same machine (the DevTools method above).
Install a browser extension such as GoFullPage or Nimbus Capture.
Use Cmd + Shift + 4 to capture the visible area, then scroll and repeat (tedious and imprecise).

If Safari is a hard requirement, a browser extension or the API is the path of least resistance.

On Windows: built-in tools

The Windows Snipping Tool (Win + Shift + S) captures the visible viewport only. There is no built-in way to scroll and stitch from the OS level. Use the Chrome DevTools method or a browser extension to get the full page.

On iPhone (iOS)

iOS 13 and later include a built-in full-page screenshot option inside Safari.

Take a regular screenshot: Side button + Volume Up on Face ID iPhones, or Home + Power on older models.
Tap the thumbnail that appears in the lower-left corner.
Tap Full Page at the top of the edit view.
Tap Done and save to Files.

Two things to know: the capture is saved as a PDF, not a PNG or WebP, and this only works in Safari, not Chrome or Firefox on iOS. If you need an actual image file, use a browser extension or the API.

On Android

Android does not have a single universal answer here.

Samsung Galaxy: Take a screenshot normally (Power + Volume Down), then tap Scroll capture in the overlay that appears at the bottom. Samsung stitches the scrolled sections automatically into one image.
Google Pixel and most stock Android: No built-in scrolling screenshot. The closest native option is Share > Print > Save as PDF in Chrome, which has the same PDF limitation as iOS.
All Android browsers: Several extensions for Chrome on Android (such as GoFullPage) add a one-tap full-page screenshot. This is the practical choice on non-Samsung devices.

Choosing the right method

Situation	Best method
Desktop, one-off manual capture	Chrome DevTools
Desktop, Firefox user	Firefox right-click > Save full page
iPhone, one-off	iOS Safari full page (saves as PDF)
Samsung Android	Scroll capture in the screenshot overlay
Other Android	Browser extension
Server, script, or CI	Screenshot API (`full_page: true`)
Mobile device, need an image file	Screenshot API
AI agent or automated workflow	Screenshot API

The pattern that works everywhere and in every format: the API. Native browser tools are fine for manual one-off captures but differ by platform, change with browser updates, and cannot be automated.

Wrapping up

Chrome DevTools and Firefox cover desktop. iOS gives you full pages but only as PDFs in Safari. Android is split: Samsung has scrolling capture built in, everyone else needs an extension. For anything automated, cross-device, or outside a desktop browser, a screenshot API with full_page: true is the consistent answer. Start capturing full pages programmatically with Grabbit's screenshot API.

Originally published on the Grabbit blog.

How to Screenshot a Website in Python (3 Approaches That Work)

Nico Acosta — Thu, 02 Jul 2026 11:38:07 +0000

There are three honest ways to screenshot a website in Python: drive Playwright, drive Selenium, or skip the browser and call an API. The code differs, but the hard parts are the same in all three: waiting for the page to be ready and capturing the full scrolling page, not just the viewport. This guide shows each approach with working code and the gotcha that bites people.

Approach 1: Playwright (the best default)

Playwright for Python launches a browser, and a full-page screenshot is one parameter:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto('https://example.com')
    page.screenshot(path='example.png', full_page=True)
    browser.close()

Install it with pip install playwright then playwright install chromium. The reason to reach for Playwright first: it auto-waits for the page to reach a stable state before the screenshot fires, so you write less timing code, and full_page=True handles the entire scrolling page in one line. It also drives Chromium, Firefox, and WebKit with the same API. See screenshots in Playwright for elements, CI, and the full-page edge cases.

Approach 2: Selenium (when you already use it)

Selenium captures the current window. In Python that is one method:

from selenium import webdriver

driver = webdriver.Chrome()
driver.get('https://example.com')
driver.save_screenshot('example.png')
driver.quit()

The catch: save_screenshot captures only the visible viewport, and Selenium has no native full-page flag. For the whole page you drive the Chrome DevTools Protocol:

import base64

result = driver.execute_cdp_cmd('Page.captureScreenshot', {
    'captureBeyondViewport': True,
    'fromSurface': True,
})
with open('full.png', 'wb') as f:
    f.write(base64.b64decode(result['data']))

This is more code and more browser-specific than Playwright, which is why Selenium is the right pick mainly when you already run a Selenium suite. The full breakdown is in screenshots in Selenium.

The gotcha both share: waiting

The most common bug in either library is capturing before the page is ready. Do not use a fixed time.sleep; wait on something real. In Selenium:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.ID, 'main-content'))
)

Playwright auto-waits for most cases, but for a specific element use page.wait_for_selector('#main-content') before capturing. For web fonts, wait on document.fonts.ready so the image does not show a fallback font.

Approach 3: Skip the browser, call an API

Both libraries above mean you install and operate a browser in Python: drivers, system libraries, memory management, and full-page workarounds. If screenshots are a production feature rather than a step in an existing script, a screenshot API removes all of that. You send one HTTP request:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

The same call from Python with requests:

import requests

res = requests.post(
    'https://api.grabbit.live/v1/grabs',
    headers={'Authorization': 'Bearer sk_live_...'},
    json={'url': 'https://example.com', 'width': 1280, 'full_page': True, 'format': 'webp'},
)
image_url = res.json()['image_url']

The response gives you a hosted image URL:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "format": "webp",
  "bytes": 48210,
  "execution_ms": 1180
}

The browser patterns map onto request parameters: viewport is width (320 to 1920) and height (240 to 1080), full page is full_page, the element pattern is a selector field, and the explicit wait becomes delay_ms (0 to 10000). format is png, jpeg, or webp.

Which to use

New code, want the least friction: Playwright. Fast setup, auto-waiting, one-line full page.
Already running Selenium: keep it, add the CDP call for full page.
Screenshots are a production feature, not a script: an API, so you do not operate a browser in Python at all.

For the framework deep dives, see screenshots in Playwright and screenshots in Selenium. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing.

Originally published on the Grabbit blog.

OG Image Examples: 10 Patterns Worth Copying (and How They Are Built)

Nico Acosta — Wed, 01 Jul 2026 11:37:36 +0000

The OG image is the first thing anyone sees before they decide to click a shared link. The best ones are not the prettiest; they are the most legible at a glance and the easiest to produce at scale. This is a tour of ten patterns that consistently work, what makes each one effective, and the build approach behind it, so you can copy the result rather than the pixels.

What separates a good OG image from a bad one

Before the examples, the rules they all follow. An OG image is usually viewed small, in a busy feed, for a fraction of a second:

One focal point. Usually the page title in large type. If a reader has to hunt, you have lost them.
High contrast and big text. It will be shrunk to a thumbnail. Thin gray text on a white card disappears.
On-brand, not generic. Color, logo, and typeface that match the site, so the card is recognizable.
Correct dimensions. 1200 by 630 pixels, the 1.91 to 1 ratio every major platform renders full-width. See OG image sizes for the full breakdown.

The patterns below are different ways to satisfy those rules.

10 patterns worth copying

Title-on-brand-gradient. The page title in large type over the site's brand gradient, with a small logo in a corner. The workhorse pattern: instantly readable, instantly recognizable, trivial to template. Most developer tools and SaaS blogs use a version of this.
Title plus author avatar. Adds the author's name and photo beside the title. Works well for blogs and newsletters where the writer is part of the draw.
Code snippet card. A syntax-highlighted snippet of the actual code the post is about. Strong for engineering content because the preview previews the substance, not just the headline.
Product screenshot inset. The title alongside a real screenshot of the product or dashboard. The honest version of "show, do not tell," and a natural fit when the page is about a UI.
Big-number stat. One large metric ("3x faster," "10,000 captures") as the focal point. Great for case studies and launch posts where a number is the hook.
Category label plus title. A small colored pill ("Guide," "Changelog") above the title, so the reader knows the content type before clicking. Good for sites with mixed content.
Minimal wordmark. Just the logo and a short tagline on a clean background. Best as a strong site-wide default for pages that do not warrant a custom image.
Quote card. A pulled quote in large type, attributed. Effective for interviews, essays, and testimonials.
Map or chart render. For data or location pages, the actual visualization as the card. This is one that pure design tools struggle with, because the image needs to be a real render of dynamic content.
Live page top-shot. The OG image is a clean screenshot of the top of the actual page. Zero separate design: the page is the preview. Ideal for landing pages and docs whose hero already looks good.

How these are actually built

Patterns 1 through 8 are layouts: a title, maybe an avatar or a stat, on a branded background. The maintainable way to produce them per page is a single template that takes the page data as input, rather than designing each card by hand. You can render that template two ways: a code-based image renderer (such as a framework's built-in OG route), or by pointing a screenshot API at a template URL you build with your normal components. The dynamic OG image generator approach walks through the template-and-capture version end to end.

Patterns 9 and 10 are different. A map render or a real screenshot of the live page is not a layout you can easily rebuild in a code renderer; it is the actual page. For those, a screenshot API is the natural fit, because it renders the real URL in a browser and hands back the image.

Generating the "live page top-shot" (pattern 10)

The simplest pattern to ship is also the one design tools cannot do: capture the real page. Point a screenshot API at the URL at OG dimensions:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yoursite.com/your-page",
    "width": 1200,
    "height": 630,
    "format": "png",
    "delay_ms": 500
  }'

The response gives you a hosted image_url to drop straight into your og:image tag:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....png",
  "width": 1200,
  "height": 630,
  "format": "png",
  "bytes": 73900,
  "execution_ms": 1210
}

Width accepts 320 to 1920 and height 240 to 1080, so 1200 by 630 is in range. delay_ms (0 to 10000) lets fonts and client-rendered content settle before the shot. Capture once per page, cache the image_url, and serve it from there.

The takeaway

Pick the pattern that fits your content, but make it per-page and make it automatic. A custom card with the post's title beats a generic logo every time, and the only way that scales past a handful of pages is a template you render on demand or a screenshot of the page itself.

New to the format? Start with what is an OG image. Ready to build one? The dynamic OG image guide has the full template-and-capture flow.

Originally published on the Grabbit blog.

How to Monitor a Website for Visual Changes

Nico Acosta — Tue, 30 Jun 2026 11:38:40 +0000

A server returning 200 does not mean the page looks right. A deploy can push broken CSS that shifts every section, a CMS edit can overwrite a hero image, or an A/B test can activate on production and change copy you did not expect. Uptime monitoring misses all of this. Visual change monitoring catches it by comparing what the page actually looks like, not just whether it responded.

The setup has three parts: capture a baseline screenshot, recapture on a schedule, and diff the two images. The rest is just wiring.

What visual change monitoring catches

Uptime monitors check that a server responds and that the response is not an error page. They know nothing about layout or content. Visual monitoring fills the gap:

CSS regressions from a bad deploy: text overflows, sections collapse, buttons disappear.
Unintended content edits: a CMS change that overwrote a heading or swapped an image.
Third-party widget breakage: a chat widget or cookie banner that started covering half the page.
A/B test leakage: a variant that activated outside its intended audience.
Competitor price changes: if you monitor external pages, any content change triggers an alert.

Visual monitoring is a catch-all for anything that changes pixels. That makes it useful both for your own production site and for tracking pages you do not control.

The monitoring loop

The loop is the same whether you build it yourself or use a hosted tool:

Capture a baseline. Screenshot the page in a known good state and store the image.
Recapture on schedule. At whatever interval matters, take a new screenshot of the same URL with the same settings.
Diff. Compare the new capture to the baseline pixel by pixel (or perceptually).
Alert or pass. If the diff is below your threshold, all is well. If it exceeds it, send an alert or fail a pipeline step.
Update the baseline. When a change is intentional, approve it as the new baseline so it does not keep alerting.

The most common failure is an inconsistent capture, not a broken diff algorithm. Animations caught mid-flight, lazy-loaded content that had not settled, or a viewport that shifted between runs all produce false positives. Making the capture deterministic is the most important part of the setup.

Setting up the capture layer

The capture needs to be consistent between runs: same viewport, same timing, same format. With a screenshot API you pin all of those at the call site:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "width": 1280,
    "full_page": true,
    "delay_ms": 800,
    "format": "png"
  }'

width keeps the layout identical between runs. full_page captures the entire document so a change anywhere on the page is visible. delay_ms waits for content to settle after page load, which prevents lazy-loaded images and animations from registering as false positives. The response includes an image_url pointing to the stored capture. Save that URL as your baseline; capture the same URL again on each check; feed both to a diff library.

To monitor a specific component rather than the full page, add "selector": "#pricing-table" and only that element is captured. The diff stays focused and noise from unrelated page sections disappears.

Diffing the captures

Two common options:

pixelmatch (Node.js) compares PNG buffers pixel by pixel and returns a count of changed pixels. Fast, well-maintained, zero dependencies. Pair it with pngjs to decode the image buffers.
resemblejs does a perceptual comparison that is more tolerant of sub-pixel rendering differences. Better for pages with anti-aliased text where a strict pixel comparison produces noisy diffs.

Set a threshold that matches how sensitive the page is. A marketing landing page with lots of imagery needs a looser threshold than a data table with precise numbers.

Dedicated tools that bundle the loop

If you prefer not to assemble the pieces yourself, these tools wrap capture, diff, and alerting together:

Visualping handles any URL with a visual or text comparison and emails you when something changes. Suited for non-technical use cases like competitor monitoring.
Hexowatch adds advanced change types (source code, technology, availability) alongside visual monitoring, with Slack and webhook alerts.
Diffy is built for comparing environments, typically staging versus production, on a schedule. Useful for confirming a deploy did not introduce a visual regression.
changedetection.io is open source and self-hostable. It covers both visual and text changes, with a clean diff view and integration hooks.

The trade-off with hosted tools is that you hand over the capture schedule and baseline storage. For a custom pipeline, you control all of it.

Scheduling and thresholds

Run frequency depends on what you are monitoring:

Production monitoring: every 15 to 60 minutes is a common range. The check runs against a live URL and alerts your on-call channel via webhook if the diff exceeds the threshold.
Deploy-triggered checks: trigger a check immediately after each deploy rather than on a fixed schedule. This is the tightest feedback loop for catching regressions.
External pages: daily checks are usually enough. If you are tracking a competitor's pricing page, a 24-hour delay is fine.

Set the diff threshold by observing a known-stable page for a few days. Measure the typical drift from ads, avatars, and minor rendering variation. Use that as your floor, then set the alert threshold above it by a comfortable margin.

For running captures at scale or across a list of URLs, see automated screenshots for the scheduling and parallelism patterns. For the capture options in detail, see the screenshot API. If you want to build this into a full visual regression suite rather than production monitoring, the best visual regression testing tools covers the open-source and SaaS options worth considering.

Originally published on the Grabbit blog.

How to Take Screenshots in Selenium (Full Page and Element)

Nico Acosta — Mon, 29 Jun 2026 11:38:34 +0000

Selenium can take a screenshot in one line, but it captures only the visible viewport by default, and unlike Playwright or Puppeteer it has no built-in full-page flag. That gap is where most of the work hides. This guide covers the basic capture, the full-page workarounds Selenium actually needs, single-element shots, and the point where an API is less effort than driving a browser.

The basic Selenium screenshot

In Python, the driver captures the current window directly:

from selenium import webdriver

driver = webdriver.Chrome()
driver.get('https://example.com')
driver.save_screenshot('example.png')
driver.quit()

In Java, you cast the driver to TakesScreenshot and choose an output type:

File shot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

Both capture the visible viewport only. If the page is taller than the window, everything below the fold is missing. This is the single biggest difference from Puppeteer and Playwright, which both expose a one-line full-page option.

Full-page screenshots (the part Selenium does not do for you)

Core Selenium has no fullPage flag. You have three real options.

1. Chrome DevTools Protocol. Selenium 4 can send CDP commands. Page.captureScreenshot with captureBeyondViewport: true renders the entire page:

result = driver.execute_cdp_cmd('Page.captureScreenshot', {
    'captureBeyondViewport': True,
    'fromSurface': True,
})
import base64
with open('full.png', 'wb') as f:
    f.write(base64.b64decode(result['data']))

2. Firefox's native method. GeckoDriver exposes a full-page call that Chrome does not:

driver.get_full_page_screenshot_as_file('full.png')  # Firefox only

3. Scroll and stitch. Resize the window to the full scroll height, then capture. This is brittle on lazy-loaded pages and pages with position: fixed headers, which repeat or float in the stitched result.

The takeaway: full-page capture in Selenium is browser-specific and more code than the other tools. If full page is your main need, that is worth knowing before you build on it.

Screenshotting a single element

Call the screenshot method on the WebElement instead of the driver. Selenium crops to the element's bounding box:

from selenium.webdriver.common.by import By

card = driver.find_element(By.ID, 'pricing-card')
card.screenshot('card.png')

If the element is below the fold, scroll it into view first so it actually renders before the capture:

driver.execute_script('arguments[0].scrollIntoView();', card)

Waiting so the capture is not blank

The most common bug is capturing before the page is ready. Use an explicit wait keyed to something real on the page rather than a fixed sleep:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.ID, 'pricing-card'))
)
driver.save_screenshot('ready.png')

For web fonts specifically, wait on document.fonts.ready via execute_script, otherwise the screenshot can show a fallback font.

Where running Selenium just for screenshots gets expensive

Selenium is a browser-testing framework. Using it only to produce images means you own everything that comes with driving a browser, none of which is the screenshot itself:

Drivers and browsers. You provision ChromeDriver or GeckoDriver, keep it matched to the browser version, and install the browser plus its system libraries in every environment.
Full-page workarounds. The CDP or scroll-and-stitch code above is yours to maintain across browser updates.
Memory and concurrency. A browser per job, closed on every error path, and a pool with back-pressure once you capture at volume.

If screenshots are the goal and the test suite is not, that is a lot of moving parts for an image.

The same capture as an API call

A screenshot API runs the browser for you. The full-page capture that took browser-specific code above becomes one request, with a real full_page flag:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

The response includes a hosted image_url you can use directly:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "format": "webp",
  "bytes": 48210,
  "execution_ms": 1180
}

The Selenium patterns map onto request parameters: viewport size is width (320 to 1920) and height (240 to 1080), full page is full_page, the element-screenshot pattern is a selector field, and the explicit wait becomes delay_ms (0 to 10000). format is png, jpeg, or webp.

Which to use

Reach for Selenium when you already run a Selenium test suite and a screenshot is one assertion or artifact among many. Reach for an API when screenshots are the actual product feature, especially if you need full-page captures and would rather not maintain CDP calls and driver versions to get them.

For the same comparison in other tools, see screenshots in Puppeteer and screenshots in Playwright. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing.

Originally published on the Grabbit blog.

How to Add Dynamic OG Images in Next.js

Nico Acosta — Sun, 28 Jun 2026 11:37:52 +0000

Next.js has dynamic Open Graph images built in: drop an opengraph-image.tsx file in a route segment and the framework generates the image and wires the meta tags. That covers most cases. The one it does not cover is when you want the OG image to be a real render of the page itself, not a separate JSX layout. This guide shows both: the native @vercel/og approach for templated cards, and a screenshot API for capturing the actual page.

The native approach: opengraph-image

In the App Router, any route segment can export an OG image. A static file is the simplest version:

app/
  blog/
    [slug]/
      opengraph-image.png   <- served automatically as the OG image
      page.tsx

Next.js detects opengraph-image.png and adds the og:image meta tags for that route. No code, no manual tags.

For a dynamic card, use opengraph-image.tsx and return an ImageResponse from next/og:

import { ImageResponse } from 'next/og';

export const size = { width: 1200, height: 630 };
export const contentType = 'image/png';

export default async function Image({ params }: { params: { slug: string } }) {
  const title = await getPostTitle(params.slug);

  return new ImageResponse(
    <div
      style={{
        width: '100%',
        height: '100%',
        display: 'flex',
        alignItems: 'center',
        justifyContent: 'center',
        background: '#0b1120',
        color: 'white',
        fontSize: 64,
        padding: 80,
      }}
    >
      {title}
    </div>,
    size
  );
}

The size export is what makes this a correct OG image: 1200 by 630 is the 1.91 to 1 ratio every major platform renders as a full-width card. For the full breakdown of why this ratio matters, see Open Graph image sizes.

This is the right tool when the card is a layout you control in JSX: a title, an author, a logo, a gradient. It runs on the edge, it is fast, and the image regenerates whenever the data changes.

Where opengraph-image falls short

@vercel/og renders a subset of CSS in an isolated environment. It does not render your actual page. That is a feature for simple cards, but it becomes a wall when the image you want is the page itself:

A dashboard or chart that already looks good and should appear in the preview as it really renders.
A page built with components, fonts, or CSS features that the OG renderer does not support, so you would have to rebuild the layout twice.
A marketing or docs page where the OG image should just be a clean shot of the top of the page.

In those cases you are no longer generating a card. You are taking a screenshot of a real page, and that is a different tool.

The screenshot approach: capture the real page

A screenshot API renders the actual URL in a real browser and hands back a hosted image. You point it at the page (or a dedicated /og route you build with your normal components) and use the result as your og:image:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yourapp.com/og/some-post",
    "width": 1200,
    "height": 630,
    "format": "png",
    "delay_ms": 500
  }'

The response includes a hosted image_url:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....png",
  "width": 1200,
  "height": 630,
  "format": "png",
  "bytes": 71240,
  "execution_ms": 1240
}

Width accepts 320 to 1920 and height 240 to 1080, so 1200 by 630 is in range. The delay_ms field (0 to 10000) gives client-rendered content or web fonts a moment to settle before the capture fires. Wire the returned image_url into your metadata:

export async function generateMetadata({ params }): Promise<Metadata> {
  const { ogImageUrl } = await getPost(params.slug);
  return {
    openGraph: {
      images: [{ url: ogImageUrl, width: 1200, height: 630 }],
    },
  };
}

Cache the result: call the API once per unique page, store image_url alongside the page record, and serve it from there so you are not capturing on every request. The same template-and-cache pattern, applied to your real page instead of a JSX card, is covered in how to generate dynamic OG images from any URL.

Which to use

Templated card (title, author, brand), no need to match the page: native opengraph-image.tsx with @vercel/og. It ships with Next.js and runs on the edge.
The OG image should be a real render of the page or app: a screenshot API. You capture what users actually see, including content @vercel/og cannot reproduce.

Many apps use both: @vercel/og for blog and marketing cards, a screenshot API for the pages that are too rich to rebuild as a card.

Before you ship, confirm the tags resolve and the card looks right by testing the live URL. New to the format? Start with what is an OG image.

Originally published on the Grabbit blog.

How to Screenshot a Website from a URL (No Browser Needed)

Nico Acosta — Sat, 27 Jun 2026 11:40:33 +0000

Every approach to capturing a screenshot from a URL falls into one of three categories: call an API, run a local headless browser, or use a client-side library. Each has a different setup cost, maintenance burden, and failure mode. Here is how to pick the right one and use it correctly.

The three approaches

Screenshot API. You send a POST request with the target URL and receive a hosted image URL in the response. The headless browser runs in the cloud. No binaries to install, no drivers to version-match, no infrastructure to keep alive.

Puppeteer or Playwright. You launch headless Chrome locally, navigate to the URL, and call .screenshot(). Full control, but you own the Chromium binary, the Node.js process, and every failure mode that comes with them.

html2canvas. Runs in the browser and serializes what is already in the DOM to a canvas. Works only client-side and misses content loaded by JavaScript after the initial render.

For server-side, automated, or high-volume capture, the API path is almost always the right call. For local dev scripts where you already have Node.js set up, Puppeteer and Playwright work well. html2canvas is the only viable option when you need a screenshot of what a user is looking at inside a browser tab.

Using a screenshot API

One POST request captures any public URL:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "height": 720,
    "format": "webp"
  }'

The response includes a hosted image_url you can store and serve directly:

{
  "id": "grb_01jx...",
  "status": "done",
  "target_url": "https://example.com",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "height": 720,
  "format": "webp",
  "bytes": 62140,
  "execution_ms": 940,
  "created_at": "2026-06-15T09:00:00.000Z"
}

Width must be between 320 and 1920 pixels; height between 240 and 1080. Format options are png, jpeg, and webp (webp is the best default for file size). Set "full_page": true to capture the full scrollable height instead of the viewport. Add "delay_ms": 1000 if the page loads content client-side before it is visible.

The same call in Python, no browser required:

import requests

resp = requests.post(
    "https://api.grabbit.live/v1/grabs",
    headers={"Authorization": "Bearer sk_live_..."},
    json={
        "url": "https://example.com",
        "width": 1280,
        "height": 720,
        "format": "webp",
    },
)
data = resp.json()
print(data["image_url"])

No chromedriver, no binary downloads, no async process to tear down after the call.

Using Puppeteer

Puppeteer gives you direct control of Chromium at the cost of managing the binary yourself:

import puppeteer from 'puppeteer';

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

Puppeteer ships Chromium at around 300 MB. It works well for local scripts, but deploying it to serverless runtimes or CI agents that lack the right system libraries is a recurring headache. See full-page screenshots with Puppeteer for the fullPage: true option and the tradeoffs versus an API.

Using Playwright

Playwright's API is nearly identical and adds Firefox and WebKit support:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.setViewportSize({ width: 1280, height: 720 });
await page.goto('https://example.com');
await page.screenshot({ path: 'screenshot.png', fullPage: true });
await browser.close();

Playwright's waitForSelector and waitForLoadState options give it a slight edge for pages with delayed content. The infrastructure burden is the same as Puppeteer.

When to use which

Scenario	Best choice
Production automation or CI	Screenshot API
Serverless function	Screenshot API
Bulk capture of many URLs	Screenshot API with async mode
Local dev script or one-off audit	Puppeteer or Playwright
Capture existing browser content (client-side)	html2canvas

Adding a headless browser process to a server that already handles your application workload is a maintenance burden. The API separates the capture concern entirely and keeps your deployment small.

Capturing multiple URLs

For bulk jobs, pass Prefer: respond-async to queue the capture without waiting for it to finish:

import requests

urls = [
    "https://example.com",
    "https://example.com/about",
    "https://example.com/pricing",
]

for url in urls:
    resp = requests.post(
        "https://api.grabbit.live/v1/grabs",
        headers={
            "Authorization": "Bearer sk_live_...",
            "Prefer": "respond-async",
        },
        json={"url": url, "width": 1280, "height": 720, "format": "webp"},
    )
    job = resp.json()
    print(job["id"], job["status"])  # poll GET /api/v1/grabs/{id} until "done"

Prefer: respond-async returns 202 immediately with a job ID. Poll GET /api/v1/grabs/{id} until status is "done", then read image_url. You can queue up to 10 concurrent jobs per team.

Waiting for dynamic content

If the target page loads content after the initial HTML is served, a plain page.goto or an instant API call may fire before the content is visible. Two options:

"delay_ms": 1500 waits a fixed number of milliseconds after the page loads before capturing. Simple, but guesswork.
"selector": "#main-content" waits until that element is present in the DOM. Tied to a real content signal, not an arbitrary timer.

For pure server-rendered pages with no client-side hydration, neither is needed.

Next steps

The automated screenshots guide covers scheduling, webhooks, and the async job queue for production capture pipelines. For capturing pages that extend beyond the viewport, see the full-page screenshot guide.

Originally published on the Grabbit blog.

Puppeteer vs Playwright for Screenshots: Which Should You Use?

Nico Acosta — Fri, 26 Jun 2026 11:37:29 +0000

If you only need to take a screenshot, Puppeteer and Playwright are closer than the endless "which is better" debates suggest. Both control a headless browser, both capture the viewport, a full page, or a single element, and the code looks almost the same in either one. The real differences show up at the edges: how many browser engines you need, how much waiting code you want to write, and whether you should be running a browser at all. This guide compares the two specifically for screenshots, not general test automation.

The short answer

Chromium-only, smallest footprint: Puppeteer. It is built around Chrome and the Chrome DevTools Protocol, so it does less and installs lighter.
Cross-browser screenshots (including Safari/WebKit): Playwright. One API drives Chromium, Firefox, and WebKit.
You want fewer flaky captures with less timing code: Playwright. Its auto-waiting fires actions after the page settles.
You do not want to run a browser at all: neither. A hosted screenshot API takes one request and returns an image.

The rest of this post shows the actual code so you can see how small the gap is.

The same screenshot in both

Here is a viewport screenshot in Puppeteer:

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle0' });
await page.screenshot({ path: 'puppeteer.png' });
await browser.close();

And the equivalent in Playwright:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'playwright.png' });
await browser.close();

The one meaningful difference is hiding in the goto call. In Puppeteer you reach for waitUntil: 'networkidle0' so you do not capture before images and fonts finish loading. Playwright auto-waits for the page to reach a stable state before the screenshot fires, so you write less timing code to get a clean capture. That auto-waiting is Playwright's biggest day-to-day ergonomic win.

Full-page screenshots

Both stitch the entire scrolling page into one tall image. The flags are nearly identical.

Puppeteer:

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

Playwright:

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

The same caveats apply to both, because they come from the page, not the library. Lazy-loaded sections that only render on scroll can come back missing, and position: fixed headers can repeat or float over the stitched image. The fix in either tool is to scroll the page to the bottom yourself before capturing so every section renders. See how to take a full-page screenshot for the scroll-to-bottom pattern that works in both.

Single-element screenshots

To capture one component, both libraries crop to an element's bounding box.

Puppeteer gets an ElementHandle and calls screenshot() on it:

const card = await page.$('#pricing-card');
await card.screenshot({ path: 'card.png' });

Playwright uses a locator, which auto-waits for the element to be ready:

await page.locator('#pricing-card').screenshot({ path: 'card.png' });

This is where auto-waiting earns its keep. In Puppeteer, page.$() returns null if the element has not rendered yet, so you add await page.waitForSelector('#pricing-card') first. Playwright's locator waits for you, so there is less to race.

Cross-browser: Playwright's real advantage

This is the one feature that is not a tie. Puppeteer is built for Chromium and Chrome (its Firefox support is experimental). Playwright drives Chromium, Firefox, and WebKit with the same API, which means you can capture the same page in the engine behind Safari without a Mac in the loop:

import { webkit } from 'playwright';

const browser = await webkit.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'safari-engine.png' });
await browser.close();

If your screenshots need to reflect how a page actually renders in Safari (different font rendering, different layout quirks), Playwright is the answer and Puppeteer is not.

Speed and memory

For a single screenshot, the library is rarely the bottleneck. Most of the wall-clock time is the page loading, not Puppeteer or Playwright. On simple Chrome-only scripts Puppeteer can be marginally faster because it does less setup, and its memory footprint is a touch smaller. Playwright's auto-waiting trades a little raw speed for more consistent captures under load, which tends to matter more once screenshots run in CI or production. If you are choosing on speed alone, you are probably optimizing the wrong thing.

Where both tools stop being worth it

Everything above runs fine on your laptop. The cost shows up in production, and it is identical for Puppeteer and Playwright because both ship the same headless browser problem:

Provisioning. Headless Chromium (and Firefox, and WebKit) need a long list of system libraries. Slim containers and serverless functions hit missing-dependency errors before the first pixel.
Memory and zombie processes. A browser not closed on every error path leaks memory and orphans processes until the box falls over.
Patching. Browser engines ship security updates constantly. A long-lived screenshot service is now a browser fleet you have to keep current.
Concurrency. One browser does one job at a time well. Ten thousand captures a day means a pool, a queue, and back-pressure to build and operate.

None of that is screenshot code. It is infrastructure, and it is the same whether you picked Puppeteer or Playwright.

The same capture as one API call

When screenshots are a production feature rather than a step inside an existing test or scraping job, a hosted screenshot API skips the browser entirely. Here is the full-page capture above as a single request to Grabbit:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "width": 1280,
    "full_page": true,
    "format": "webp"
  }'

The response includes a hosted image_url you can use directly:

{
  "id": "grb_01jx...",
  "status": "done",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....webp",
  "width": 1280,
  "format": "webp",
  "bytes": 48210,
  "execution_ms": 1180
}

The options you reach for in both libraries map onto request parameters: fullPage becomes full_page, the element handle or locator becomes a selector field, and the manual wait becomes delay_ms (0 to 10000). Width accepts 320 to 1920, height 240 to 1080, and format is png, jpeg, or webp.

Which to choose

Already running Puppeteer for Chrome work? Keep it. Adding a screenshot is one line.
Need cross-browser captures, or want less timing code? Playwright.
Screenshots are a feature you ship, not a side effect of a test? Skip the browser and call an API.

For the framework-specific deep dives, see taking screenshots in Puppeteer and taking screenshots in Playwright. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing.

Originally published on the Grabbit blog.