DEV Community: Grabbit

The Best Visual Regression Testing Tools (Open Source and SaaS)

Nico Acosta — Thu, 25 Jun 2026 11:37:10 +0000

If you search for visual regression testing tools you get a wall of "top 10" lists that all name slightly different products. This is a shorter, opinionated map: the open-source options worth starting with, the SaaS platforms worth paying for, and the one thing every tool depends on but few of the lists mention, a consistent capture.

For a primer on the workflow itself, see visual regression testing: a practical guide. This post is about choosing a tool.

How the tools differ (the three questions that matter)

Every visual regression tool runs the same capture, diff, review, approve loop. They differ on three axes:

What it captures: isolated components, a local dev server, or deployed URLs.
Where it runs: your CI (open source) or a hosted service (SaaS).
How you review diffs: a generated HTML report, or a managed dashboard with baseline approval.

Match those to how you already build and the choice gets easy.

Open source tools

Playwright ships expect(page).toHaveScreenshot(), which captures and diffs against a stored baseline in one assertion. If you already run Playwright for end-to-end tests, this is the lowest-friction start. See how to take screenshots in Playwright for the capture options.
BackstopJS is the long-standing choice for page-level scenarios. You define viewports and URLs in a config file, and it generates a clean diff report. Good when you are testing pages rather than components.
Argos focuses on the review experience: it ingests screenshots from your CI and gives you a GitHub-integrated diff UI, with a self-hostable option.
Loki is built for Storybook, capturing each story as a component snapshot. A natural fit if your design system already lives in Storybook.

These cover most needs without a subscription. The trade-off is that you own the infrastructure: running the browsers, storing baselines, and wiring the report into CI.

SaaS platforms

Chromatic is the managed companion to Storybook, made by the Storybook team. It renders every story across browsers and gives you a review-and-approve workflow. Strong for component-driven teams.
Percy (part of BrowserStack) snapshots responsive pages and integrates tightly with CI, with a hosted dashboard for baseline management.
Applitools leads on comparison technology: its Visual AI aims to flag meaningful changes while ignoring noise like anti-aliasing, which reduces false positives at scale.
Sauce Labs bundles visual testing into a broader cross-browser cloud, useful if you already run functional tests there.

You pay for the review dashboard, cross-browser rendering, and not having to maintain capture infrastructure yourself.

The part every tool depends on: a consistent capture

A visual diff is only as trustworthy as the screenshot under it. The reason teams mute their visual suites is flakiness, and flakiness almost always comes from the capture step, not the diff: animations caught mid-flight, lazy-loaded content that had not settled, fonts loaded a frame late, or a viewport that drifted between baseline and comparison.

Component-bound tools control this by rendering in a sandbox. But when you want to test deployed URLs (staging, preview deploys, production canaries), you need a capture that looks identical every run, given the same input, without standing up and scaling headless browsers in CI. A screenshot API gives you exactly that:

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

Pinning width keeps the layout identical between runs, full_page captures the whole document, and delay_ms waits for content to settle so lazy-loaded sections do not register as false diffs. Store the returned image_url as your baseline, capture the same URL on each deploy, and feed both images into whichever diff tool you picked above. Grabbit does not diff images for you; it is the deterministic capture layer your chosen tool builds on.

Which one should you pick?

Already using Playwright: add one toHaveScreenshot assertion and grow from there.
Component library in Storybook: Loki (open source) or Chromatic (managed).
Testing deployed pages, want it free: BackstopJS or Argos, fed consistent captures.
Want a managed dashboard and minimal upkeep: Percy or Applitools.

Whatever you choose, start with a handful of high-value screens, make the captures deterministic first, and only expand once the suite is quiet enough to trust. For running captures on a schedule or across many URLs, see automated screenshots, and for every capture option see the screenshot API.

Originally published on the Grabbit blog.

How to Take Screenshots in Playwright (Full Page, Elements, CI)

Nico Acosta — Wed, 24 Jun 2026 11:37:41 +0000

page.screenshot() does the job in two lines for a local capture or a test assertion. The friction arrives later: full-page shots that get clipped by sticky headers, Chromium installation issues in CI, and the long tail of keeping a browser fleet running in production. This guide covers the screenshot methods that work, the ones with hidden edge cases, and the point where offloading to an API makes more sense.

The basic Playwright screenshot

Launch a browser, open a page, capture:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();

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

await browser.close();

The waitUntil: 'networkidle' option is worth stating explicitly. The default load event fires as soon as the HTML and blocking scripts are done, but client-rendered content, web fonts, and lazy-loaded images often arrive later. networkidle waits until there are no network connections open for at least 500ms, which is a much better proxy for "the page actually looks right."

Full-page screenshots

By default page.screenshot() captures the viewport only. To capture the full scrolling page, set fullPage: true:

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

Playwright expands the viewport to the document's full scroll height before capturing. This works reliably on most static pages.

Two things break it:

Sticky and fixed-position elements. A header with position: fixed renders in its normal viewport position for every "slice" Playwright captures, so it can appear repeated or floating over content in the final stitched image. There is no clean built-in workaround short of hiding the element with a page.addStyleTag before capturing.
Lazy-loaded content. If a page only renders sections when they scroll into view, fullPage: true can come back short. Scroll the page yourself before capturing to trigger those renders:

await page.evaluate(async () => {
  await new Promise<void>((resolve) => {
    let scrolled = 0;
    const step = 500;
    const timer = setInterval(() => {
      window.scrollBy(0, step);
      scrolled += step;
      if (scrolled >= document.body.scrollHeight) {
        clearInterval(timer);
        window.scrollTo(0, 0);
        resolve();
      }
    }, 100);
  });
});

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

Screenshotting a specific element

Playwright's locator API makes element-level captures cleaner than Puppeteer's ElementHandle approach. Call .screenshot() on any locator and Playwright crops to that element's bounding box:

// Capture a single component by CSS selector
await page.locator('#pricing-card').screenshot({ path: 'card.png' });

// Or by role
await page.getByRole('dialog').screenshot({ path: 'modal.png' });

If the element is below the fold, Playwright scrolls it into view before capturing. If the selector matches nothing, the call throws, so wrap it in a waitFor when the element might not be immediately present:

const card = page.locator('#pricing-card');
await card.waitFor({ state: 'visible' });
await card.screenshot({ path: 'card.png' });

Format and quality options

Playwright defaults to PNG. For production use cases where file size matters, switch to JPEG or WebP:

await page.screenshot({
  path: 'page.webp',
  type: 'webp',
  quality: 85, // 0–100, only for jpeg and webp
});

PNG is lossless and best for visual regression tests where pixel-level accuracy matters. JPEG and WebP are better for images that will be served over HTTP, since they are significantly smaller at comparable quality.

Screenshots in CI with GitHub Actions

Installing Playwright in CI requires browser binaries and their system dependencies. Use npx playwright install --with-deps (not just npx playwright install) to pull in the OS libraries Chromium needs:

- name: Install Playwright browsers
  run: npx playwright install --with-deps chromium

- name: Run tests
  run: npx playwright test

- name: Upload test artifacts
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-report
    path: test-results/
    retention-days: 7

The if: always() on the upload step is important: test artifacts are most useful when tests fail, and a plain if: success() would skip the upload precisely when you need the diffs.

Playwright's --with-deps flag is the most common CI pitfall. Without it, Chromium launches fine locally (because those libraries are already installed) but fails in a minimal CI container with a cryptic error while loading shared libraries message.

Visual regression with screenshots

Playwright's built-in snapshot assertion compares a screenshot against a stored baseline:

await expect(page).toHaveScreenshot('homepage.png');

On the first run, Playwright writes the baseline to __snapshots__/. On subsequent runs it compares pixel-by-pixel and fails if the diff exceeds the configured threshold. Pass { maxDiffPixelRatio: 0.01 } to tolerate minor anti-aliasing differences:

await expect(page.locator('.hero-section')).toHaveScreenshot('hero.png', {
  maxDiffPixelRatio: 0.01,
});

For a longer look at visual regression workflows, the visual regression testing guide covers when snapshot tests make sense and how to keep them from becoming brittle.

Where running Playwright yourself gets costly

Playwright is the right tool for test suites that already drive a browser. When screenshots are a standalone production feature, the overhead adds up:

Chromium in production. Deploying a headless browser to a serverless function means bundling system libraries, increasing cold-start times, and hitting the payload size limits of most platforms.
Concurrency. One browser instance handles one capture at a time well. Handling bursts means a pool, a queue, and back-pressure logic.
Security surface. A browser that can render arbitrary user-submitted URLs needs SSRF protection (block private IP ranges), sandboxing, and regular security patches.

This is the point where a dedicated screenshot API is faster to operate: the browser fleet, SSRF guards, and scaling are someone else's problem.

The same capture as an API call

Here is the full-page capture above as a single request to Grabbit. No browser to provision or patch:

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,
    "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": 52340,
  "execution_ms": 1240
}

The Playwright options you reach for most translate directly: fullPage: true becomes "full_page": true, the element locator pattern becomes a "selector" field, and manual wait time becomes "delay_ms" (0 to 10000). Width accepts 320 to 1920, height 240 to 1080, and "format" is "png", "jpeg", or "webp".

# capture one component after waiting for it to settle
-d '{
  "url": "https://example.com/dashboard",
  "selector": "#chart-container",
  "delay_ms": 800,
  "format": "png",
  "width": 1280,
  "height": 720
}'

Which to use

Use Playwright directly when screenshots are part of a test suite that already controls a browser, or when you need precise assertions against local builds that are not reachable from the internet. Use an API when screenshots are a production feature and you would rather ship in an afternoon than build a browser fleet.

For a head-to-head look at Puppeteer's API versus Playwright's for captures, see the Puppeteer screenshot guide. If you are picking a hosted screenshot service, the screenshot API comparison covers the trade-offs honestly.

Originally published on the Grabbit blog.

How to Test and Preview Your OG Image Before Publishing

Nico Acosta — Tue, 23 Jun 2026 11:39:33 +0000

You added an og:image tag, pushed your changes, shared the link, and the preview is wrong: the old image, a cropped logo, or nothing at all. The fix is to preview the card before you publish, not after. This guide covers the fastest ways to test an OG image, including the case the online tools cannot handle: a page running on localhost.

The short answer

Run your page URL through a free Open Graph checker. The three that fetch your live page and render the card the way each platform would:

opengraph.xyz scans any URL and previews the card across Facebook, X, LinkedIn, and more.
Open Graph Validator (Orca Scan) lists every tag it found and flags what is missing.
DebugBear's OG checker validates the tags and the image dimensions.

Paste your URL, read the rendered card, fix any tag it flags, redeploy. That covers a page that is already live. The harder cases are below.

Use the platform debuggers for the real result

The general checkers above are fast, but the platforms cache what they scrape, and that cache is what users actually see. To test against the real thing and to clear a stale preview, go to the source:

Facebook: Sharing Debugger. Shows exactly what the crawler sees and has a Scrape Again button to force a fresh fetch.
LinkedIn: Post Inspector. Re-fetches on every check, so it doubles as a cache buster.
X (Twitter): X reads og:image, but the large card only renders when twitter:card is set to summary_large_image. The simplest live test is to paste the URL into a draft post and look at the attached card before sending.

If you changed your image and the old one still appears, this is almost always a cache issue. Re-scrape through Facebook's debugger or LinkedIn's inspector and it clears within minutes.

How to test an OG image on localhost

This is the question the online tools cannot answer. A social debugger runs on the platform's servers, so it has no route to http://localhost:3000. You have two options.

Option 1: expose localhost with a tunnel. Run a tunnel like ngrok to get a public URL that points at your local server, then paste that URL into any of the checkers above. This gives you the real unfurl preview while your code is still local.

Option 2: capture the OG template directly. If your OG images are generated from an HTML template (the scalable pattern, where one /og route renders the title and branding), you do not need a social crawler to see the image. You need to see what the template renders at 1200 by 630. Point a screenshot API at the template URL and inspect the returned image:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-tunnel.ngrok.app/og?title=My+Post+Title&category=Guides",
    "width": 1200,
    "height": 630,
    "format": "png"
  }'

The response returns a hosted image_url showing exactly what your template produces at the OG card size. You are checking the rendered pixels (Is the title cut off? Does the logo fit? Is the contrast readable?) rather than the social unfurl. Use a sk_test_ key while you iterate; test grabs return a deterministic placeholder and never cost a credit, so you can capture as often as you like while tuning the template.

A pre-publish checklist

Before you ship a page, confirm:

og:image points to an absolute URL (including https://), not a relative path. Crawlers do not resolve relative paths.
The image is at least 600 by 315, ideally 1200 by 630. Below the minimum, the card collapses to a thumbnail.
og:image:width and og:image:height are set so the platform reserves the right space.
twitter:card is set to summary_large_image if you want the large card on X.
The image URL is publicly reachable, with no auth wall or redirect in front of it. Some crawlers do not follow redirects.
Your meta tags are server-rendered, not injected by client JavaScript. Crawlers run little to no JS.

If all six pass and the debugger still shows the wrong image, force a re-scrape to clear the cache.

Why previewing matters more for dynamic images

A single hand-made OG image is easy to eyeball once. But the moment you generate images dynamically (one per blog post, one per product, one per user) you cannot manually check every output. That is exactly when previewing through a screenshot API pays off: the same call that generates the image is the call that lets you inspect it, so you can catch a clipped title or an overflowing string before any of them go live.

This is the workflow Grabbit's screenshot API is built for. Render your OG template, capture it at 1200 by 630, store the returned image_url, and drop it into your og:image tag. Start with a free test key to dial in the template, then switch to a live key for production captures.

Wrapping up

To preview an OG image before publishing: run the live URL through opengraph.xyz or a platform debugger, force a re-scrape if a stale image is cached, and for localhost either tunnel the page out or capture your OG template directly with a screenshot API. For the tags themselves see what an OG image is and why links break, and for the exact pixel sizes see Open Graph image sizes and dimensions. To automate the generation step, read how to generate dynamic OG images from any URL.

Originally published on the Grabbit blog.

What Is an OG Image? Why Your Shared Links Look Broken

Nico Acosta — Mon, 22 Jun 2026 12:08:43 +0000

When someone shares your URL on Slack, X, or LinkedIn, the platform fetches a small metadata snapshot of your page and renders a preview card. The image in that card is the OG image. If you have not explicitly set one, the platform either guesses (often badly) or shows nothing at all.

What "OG" stands for

OG is short for Open Graph, a protocol Facebook introduced in 2010 to give websites a standard way to describe themselves to social crawlers. The spec defines a set of <meta> tags you put in your page's <head>. The most important ones are:

<meta property="og:title"       content="Page title" />
<meta property="og:description" content="One-sentence description." />
<meta property="og:image"       content="https://yoursite.com/og/home.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:url"         content="https://yoursite.com/" />

Every major platform reads these tags: Facebook, LinkedIn, X, Slack, Discord, iMessage, WhatsApp, and Teams. The og:image tag is the one that fills the visual slot in the preview card.

Why shared links look broken without one

When a platform crawler visits your URL and finds no og:image tag, it either:

Picks the first image it finds on the page (often a logo, icon, or product thumbnail that was not designed for 1200 by 630)
Falls back to a gray placeholder
Shows nothing

None of those outcomes help. A broken preview costs clicks because users cannot tell at a glance what the link is about. A well-set OG image does the opposite: it communicates the content before anyone reads the title.

The standard dimensions

The universally safe size is 1200 by 630 pixels (a 1.91:1 ratio). This is what Facebook, LinkedIn, X, Slack, and Discord all render as a full-width card. Below 600 by 315 most platforms shrink the image to a small thumbnail beside the title instead of a full card.

Set the width and height tags alongside the image URL:

<meta property="og:image"        content="https://yoursite.com/og/post-slug.webp" />
<meta property="og:image:width"  content="1200" />
<meta property="og:image:height" content="630" />

For exact breakdowns by platform see Open Graph image sizes and dimensions.

X (Twitter) cards

X reads og:image automatically, but to trigger the large preview format you need one extra tag:

<meta name="twitter:card"  content="summary_large_image" />
<meta name="twitter:image" content="https://yoursite.com/og/post-slug.webp" />

Without twitter:card set to summary_large_image, X collapses your preview to a small thumbnail regardless of your og:image dimensions.

Why one image per page beats one image for everything

A global fallback image (like your homepage hero) keeps every shared link looking identical. A per-page OG image tells the reader at a glance what that specific page is about. Blog posts, product pages, and documentation pages all carry different information, and the preview card is the first signal users see in a feed.

The friction here is design. Creating a unique image for every page does not scale unless you automate it.

Automating OG images with a screenshot API

The scalable approach: build one HTML template that renders your brand, title, and description at 1200 by 630, then capture it with a screenshot API once per page. The template lives in your codebase; the API handles the headless browser.

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yoursite.com/og?title=What+Is+an+OG+Image&category=Guides",
    "width": 1200,
    "height": 630,
    "format": "webp"
  }'

The response gives you a hosted image_url you can use directly in your og:image tag:

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

Call the API once at publish time or on the first request, store the returned URL, and serve it on every subsequent visit. One API call per unique page; no design tool required.

For a step-by-step walkthrough of the template-and-capture pattern see How to generate dynamic OG images from any URL. For full API details see the Grabbit screenshot API.

Checking what your OG image actually looks like

After adding the tags, verify the result before publishing:

Facebook: Sharing Debugger shows exactly what the crawler sees and lets you force a re-scrape to clear stale cache.
LinkedIn: Post Inspector works the same way.
X: The X Card Validator previews the card layout, including whether summary_large_image is triggering.

Crawlers cache aggressively. If you update your og:image tag and the old image still shows up, hit the platform's debugger to force a fresh fetch. For the full preview workflow, including how to test from localhost, see how to test and preview your OG image before publishing.

Common reasons the tag is set but the image still does not appear

The image URL returns a redirect instead of the image directly; some crawlers do not follow redirects
The image is behind authentication or a firewall the crawler cannot reach
The image is smaller than 200 by 200 pixels (Facebook's minimum for displaying a full-width card)
The page renders the og:image tag via JavaScript after load; crawlers typically execute little to no JavaScript, so server-render your meta tags

Server-side rendering or static generation of meta tags is the reliable approach. If your framework generates og:image at request time on the server, the crawler will always see it.

Originally published on the Grabbit blog.

How to Capture a Full-Page Screenshot in Google Chrome

Nico Acosta — Sun, 21 Jun 2026 12:06:25 +0000

The fastest way to capture a full-page screenshot in Chrome needs no extension at all: open DevTools, run one command, and Chrome stitches the entire scrolling page into a single image. This guide covers that built-in method, the extension route if you want a one-click button, and how to automate full-page captures once you need them for more than one page at a time.

The built-in DevTools method (no extension)

Chrome ships a full-page capture inside Developer Tools. It is the method most "scrolling screenshot" guides eventually point you to, and it works on every desktop platform:

Open the page you want to capture.
Open DevTools: F12, or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on Mac.
Open the Command Menu: Ctrl+Shift+P on Windows and Linux, or Cmd+Shift+P on Mac.
Type screenshot, then select Capture full size screenshot.

Chrome scrolls the whole page, stitches it into one tall PNG, and downloads it to your default folder. This captures the entire document height, not just the part visible in the window, which is the difference between this and a normal screenshot.

If you only want the visible area, the same menu offers Capture screenshot, and Capture node screenshot grabs a single selected element from the Elements panel.

The extension route

If you would rather click a button than open DevTools each time, a full-page screenshot extension adds one to the toolbar. GoFullPage is the most widely used, and ScreenshotOne and similar tools offer browser extensions too. The trade-off: an extension can see the pages you capture, so for sensitive or internal pages the built-in DevTools method keeps everything local.

Save as PDF instead

If you need a document rather than a PNG, Chrome's print dialog does full-page export:

Press Ctrl+P (Windows/Linux) or Cmd+P (Mac).
Set the destination to Save as PDF.
Click Save.

This captures the full page as vector text where possible, which is better than an image if the page is mostly type.

When the manual method stops scaling

Everything above is one page at a time, by hand. That is fine for a handful of captures. It falls apart the moment you need full-page screenshots:

across dozens or hundreds of URLs (a sitemap audit, competitor research),
on a schedule (visual monitoring, change detection),
inside CI (visual regression tests on every deploy),
or generated on demand (social preview images per page).

For any of those, you want an API call instead of a person and a keyboard. A screenshot API runs a real Chromium render on its side and returns a hosted image, so you script the capture instead of performing it.

Automating full-page captures

Here is the same full-page capture as a single request to Grabbit. Set full_page to true and you get the entire scrolling page back, exactly like the DevTools command:

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 store or display directly:

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

To capture many pages, loop over your list of URLs and send one request each. Width accepts 320 to 1920, format is png, jpeg, or webp, and delay_ms (0 to 10000) waits for late-rendering content before the shot fires. If a page lazy-loads sections, delay_ms plays the same role as scrolling the page yourself in DevTools.

Which method to use

Reach for the DevTools Command Menu for a quick one-off capture: it is built in, local, and needs nothing installed. Reach for an extension if you want a permanent toolbar button and the pages are not sensitive. Reach for an API when capturing is a repeated or automated job and doing it by hand no longer makes sense.

For the cross-tool breakdown of full-page capture (including Firefox, Edge, and code approaches), see how to take a full-page screenshot. If you are already scripting captures in code, full-page screenshots in Puppeteer covers the same job in Node.

Originally published on the Grabbit blog.

Full-Page Screenshots in Puppeteer (and When an API Is Faster)

Nico Acosta — Sat, 20 Jun 2026 12:08:42 +0000

page.screenshot() is the whole API, and for a one-off capture on your laptop it is genuinely two lines of code. The work starts after that: full-page captures that come back cut off, fonts that render as fallbacks, and a headless Chromium process that eats memory in production. This guide covers the Puppeteer screenshot methods that work, the ones that quietly fail, and the point where running your own browser stops being worth it.

The basic Puppeteer screenshot

Launch a browser, open a page, navigate, capture:

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

await browser.close();

The one detail that matters here is waitUntil: 'networkidle0'. The default for goto resolves as soon as the load event fires, which is often before images, web fonts, and client-rendered content are on the page. networkidle0 waits until there have been no network connections for 500ms, which is a much better proxy for "the page is actually done."

Full-page screenshots

By default page.screenshot() captures only the viewport. To capture the entire scrolling page, set fullPage: true:

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

Puppeteer measures the full scroll height and stitches the result into a single tall image. This works on most static pages. It breaks on two kinds of page:

Lazy-loaded content. If a page only renders sections as they scroll into view, a full-page capture can stop short because the lower sections never rendered. The fix is to scroll the page to the bottom yourself before capturing, then scroll back to the top.
Sticky and fixed elements. A header with position: fixed can repeat down the stitched image or float over content, because the element stays pinned in the viewport while Puppeteer scrolls underneath it.

Here is the scroll-to-bottom workaround for lazy pages:

await page.evaluate(async () => {
  await new Promise((resolve) => {
    let total = 0;
    const step = 400;
    const timer = setInterval(() => {
      window.scrollBy(0, step);
      total += step;
      if (total >= document.body.scrollHeight) {
        clearInterval(timer);
        window.scrollTo(0, 0);
        resolve();
      }
    }, 100);
  });
});

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

Screenshotting a single element

To capture one component instead of the whole page, get an ElementHandle and call screenshot() on it. Puppeteer crops to that element's bounding box:

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

If page.$() returns null, the selector did not match yet. Use await page.waitForSelector('#pricing-card') first so you are not racing the render.

Higher-quality captures

Two settings control how sharp the output looks:

await page.setViewport({
  width: 1280,
  height: 720,
  deviceScaleFactor: 2, // capture at 2x for a crisp, retina-density image
});

// PNG is lossless; for JPEG you can trade size for quality
await page.screenshot({ path: 'sharp.jpg', type: 'jpeg', quality: 90 });

deviceScaleFactor: 2 doubles the pixel density, which is the single biggest win for screenshots that will be displayed on high-resolution screens. Beyond that, the most common quality bug is not resolution at all: it is capturing before web fonts have loaded, so the screenshot shows a fallback font. Wait for fonts explicitly when it matters:

await page.evaluate(() => document.fonts.ready);

Where running Puppeteer yourself gets expensive

Everything above runs fine on your machine. Production is where the cost shows up, and none of it is about the screenshot code:

Provisioning Chromium. Headless Chromium needs a long list of system libraries. In a slim container or a serverless function you hit missing-dependency errors before you capture a single pixel.
Memory and zombie processes. A browser that is not closed on every error path leaks memory. Under load you accumulate orphaned Chromium processes until the box falls over.
Patching. Chromium ships security updates constantly. A long-lived screenshot service is a browser you now have to keep current.
Concurrency. One browser handles one job at a time well. Ten thousand captures a day means a pool, a queue, and back-pressure, which is real infrastructure to build and operate.

This is the point where a hosted screenshot API is faster to ship: someone else runs the browser fleet, and you send one HTTP request.

The same capture as an API call

Here is the full-page capture above as a single request to Grabbit. No browser to install, patch, or scale:

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 Puppeteer options you reach for most map directly onto request parameters: fullPage becomes full_page, the element handle pattern 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.

# capture one element, after waiting 500ms for it to settle
-d '{
  "url": "https://example.com/pricing",
  "selector": "#pricing-card",
  "delay_ms": 500,
  "format": "png"
}'

Which to use

Reach for Puppeteer directly when you are already driving a browser for other reasons (scraping, end-to-end tests) and a screenshot is one more step, or when you need a one-off capture during development. Reach for an API when screenshots are a production feature and you would rather not operate a browser fleet to ship it.

For the full breakdown of full-page capture techniques across tools, see how to take a full-page screenshot. 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 Generate Dynamic OG Images from Any URL

Nico Acosta — Fri, 19 Jun 2026 12:07:26 +0000

Most sites share links with a broken card or a generic company logo. The pages that get clicks have a sharp 1200 by 630 image that shows the post title and brand. Designing that image in a tool does not scale past a handful of pages. The approach that does: one HTML template, captured by an API, cached forever.

Why a template-and-capture approach

A dynamic OG image has the same data as the page it represents: a title, maybe a description or author. If you can render that data in HTML, a screenshot API can turn it into an image. The template lives in your codebase, the API handles the browser, and you never open a design tool.

This pattern also means a single CSS change to the template updates every OG image across the site. No re-exporting, no version drift.

Step 1: Build the template page

Create a route at /og that reads query parameters and renders a styled card at 1200 by 630. A minimal server-rendered example in any framework looks like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <style>
      * { box-sizing: border-box; margin: 0; padding: 0; }
      body {
        width: 1200px;
        height: 630px;
        display: flex;
        flex-direction: column;
        justify-content: center;
        padding: 80px;
        background: #0f172a;
        font-family: system-ui, sans-serif;
      }
      .eyebrow { color: #60a5fa; font-size: 24px; margin-bottom: 24px; }
      .title   { color: #f8fafc; font-size: 68px; font-weight: 700; line-height: 1.1; }
      .logo    { position: absolute; bottom: 48px; right: 80px; color: #94a3b8; font-size: 20px; }
    </style>
  </head>
  <body>
    <div class="eyebrow">{{ category }}</div>
    <div class="title">{{ title }}</div>
    <div class="logo">yoursite.com</div>
  </body>
</html>

Swap the Mustache-style placeholders for whatever your server framework uses. Keep the body fixed at 1200 by 630 so the viewport matches the capture size exactly. Add your actual brand colors, a logo SVG, or a background gradient, then preview the page in a browser to confirm it looks right before automating the capture.

Step 2: Capture the template with a screenshot API

Once the template is live at a public URL, generating an image is one POST request:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yoursite.com/og?title=How+to+Build+a+Screenshot+API&category=Guides",
    "width": 1200,
    "height": 630,
    "format": "webp"
  }'

The response includes a hosted image_url you can drop directly into your og:image tag:

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

Use "format": "webp" for smaller file sizes. If your template renders text via JavaScript instead of server-side, add "delay_ms": 500 to give the script time to run before the capture fires.

Making it dynamic

The URL is the variable part. For a blog, construct the template URL per post and call the API once at publish time or on the first request:

async function generateOgImage(title: string, category: string): Promise<string> {
  const templateUrl = new URL('https://yoursite.com/og');
  templateUrl.searchParams.set('title', title);
  templateUrl.searchParams.set('category', category);

  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: templateUrl.toString(),
      width: 1200,
      height: 630,
      format: 'webp',
    }),
  });

  const grab = await res.json();
  return grab.image_url; // store this; don't call the API again on repeat visits
}

Store the returned image_url in your CMS, database, or a build-time JSON file. On every subsequent request, serve the stored URL. The API call runs once per unique image.

Waiting for JavaScript-rendered content

If your template depends on a framework that hydrates after the initial HTML is served, the screenshot may fire before the text is visible. Two options:

Fixed delay: "delay_ms": 800 waits that many milliseconds after the page loads.
Element selector: "selector": "#title" waits until that element is present in the DOM before capturing. This is more reliable than a fixed delay because it ties the capture to a real content signal rather than a guess.

For a pure server-rendered template, neither option is needed.

Caching and the og:image meta tag

Once you have the image_url, wire it into your page head:

<meta property="og:image" content="https://cdn.grabbit.live/grabs/grb_01jx....webp" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://cdn.grabbit.live/grabs/grb_01jx....webp" />

Set og:image:width and og:image:height so platforms reserve the right space without fetching the image first. For the twitter:card value, summary_large_image is the one that renders the big preview on X.

Wrapping up

The full workflow: build one HTML template, pass page data as query parameters, call the Grabbit screenshot API once, store the image_url, and serve it from your og:image tag. Update the template design once and every image refreshes on the next capture.

For exact OG image dimensions and what each platform expects, see Open Graph image sizes and dimensions.

Originally published on the Grabbit blog.

The Best Screenshot APIs in 2026 (An Honest Comparison)

Nico Acosta — Thu, 18 Jun 2026 07:46:45 +0000

Most "best screenshot API" posts are affiliate-link roundups. Ratings correlate with payout, not with what actually fits your use case. This post uses verified pricing data (June 2026) and compares on the criteria that matter for developers: billing model, per-grab cost, features, and how well the API fits automation and agent workflows.

What to look for

These are the dimensions that separate one screenshot API from another in practice:

Billing model. Monthly subscriptions reset unused credits every cycle. If your volume is spiky or seasonal, you pay for capacity you do not use. Annual flat plans and prepaid credits do not reset. For variable workloads, the billing model often matters more than the per-grab rate.

Per-grab cost. At moderate volume, rates range from $0.0002 to $0.0079 per capture. A higher per-grab rate is not always worse: some providers include features (cookie consent, selector targeting) that others charge extra for or omit entirely.

Core features. Full-page capture, custom viewport, output format (PNG/JPEG/WebP), delay_ms wait controls for JavaScript-heavy pages, and CSS selector clipping are the set you need for any non-trivial pipeline. Cookie-consent dismissal is increasingly important for EU-targeted apps.

Agent and automation support. APIs built for AI pipelines offer an MCP server or a one-line integration path. Most existing tools were designed before agent frameworks existed and require custom glue code.

How the options compare

Prices verified June 2026 from each provider's public pricing page, normalized to approximately 10,000 grabs per month. Browserless and Thum.io list a lower per-grab rate than Grabbit; the trade-offs are detailed below.

Provider	Per grab	Billing	Included	Waste	Full page	Wait + selector	Cookie consent	Agent
Grabbit	$0.002	Annual flat	25,000/yr	None	Yes	Yes	Yes	One-line
ScreenshotOne	$0.0079	Monthly	2,000/mo	Resets	Yes	Yes	Yes	MCP
ScrapingBee	$0.0049	Monthly	~10,000/mo	Resets	Yes	Yes	No	MCP
Browserless	$0.0013	Monthly	20,000 units/mo	Resets	Yes	Yes	Yes	MCP
Urlbox	$0.0066	Monthly	2,000/mo	Resets	Yes	Yes	Yes	None
ApiFlash	$0.0035	Monthly	1,000/mo	Resets	Yes	Yes	Yes	None
ScreenshotMachine	~$0.003	Monthly	2,500/mo	Resets	Yes	Yes	No	None
Thum.io	$0.0002	Usage metered	$1–$20/mo min	Minimum	No	No	No	None

The options explained

Grabbit is a REST endpoint: POST a URL, get back a hosted image_url. The $50/yr flat plan includes 25,000 captures that never reset. Full-page, custom viewports (320–1920 px), all three output formats, delay_ms wait, selector clipping, and cookie-consent handling are all included. An MCP server lets AI agents call it without any custom integration code.

ScreenshotOne is the most established provider, with SDK coverage across Ruby, PHP, Go, Java, C#, and more. At $0.0079/grab it is the highest rate in this table, but if your backend is not JavaScript, the maintained first-party SDKs are a genuine advantage.

Browserless has the lowest per-grab rate among full-featured providers at $0.0013. The important caveat: it is a managed headless browser service, not a simple screenshot endpoint. You connect via Puppeteer or Playwright and write your own automation scripts. More powerful than a REST API for complex workflows; more work to set up for a straightforward URL-to-image use case.

Urlbox has the longest track record and offers enterprise SLAs. At $0.0066/grab it is on the expensive side, but it is a well-maintained product for teams with strict uptime requirements.

ApiFlash and ScrapingBee are solid mid-range options. ScrapingBee uses a credit system (approximately 25 credits per grab) and lacks cookie-consent dismissal, which causes captures to be blocked by consent banners in EU-targeted apps.

Thum.io has the lowest per-grab rate ($0.0002) with a minimum monthly charge. The trade-off is a limited feature set: no full-page capture, no wait controls, no selector targeting, and no agent support. It works for simple thumbnail generation but not for production automation pipelines.

Making your first request

Every provider has a different auth scheme and parameter set. Here is a Grabbit request to illustrate the pattern: one endpoint, one auth header, explicit viewport:

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",
    "full_page": false
  }'

The response includes image_url (the hosted screenshot), bytes, execution_ms, and id. Add delay_ms (up to 10000) to wait for page content to finish loading, or selector to clip to a specific element. Switch to a sk_test_ key for development and CI: test captures return a placeholder image at no charge.

Billing model matters more than per-grab rate

Monthly subscription comparisons look clean in a table but obscure real cost for variable workloads. A team doing 2,000 grabs in January and 15,000 in March pays the full monthly allowance both months on a reset plan.

Prepaid credits and annual plans eliminate this: you buy a block and it covers actual usage with nothing evaporating at the end of the cycle. This makes budgeting predictable and avoids the "use it or lose it" pressure that leads teams to pad their capture volume to justify the plan.

For AI agents and automation

Most screenshot APIs were designed before agent frameworks existed. The current integration pattern is: get an API key, call the endpoint from backend code. That works, but it requires custom glue code for every agent that needs visual data.

Agent-native design means the tool registers itself as a callable function in an agent framework. An agent can capture a screenshot and get back a hosted URL to pass downstream with no extra setup. This is the pattern that makes screenshot APIs useful for research agents, monitoring pipelines, and content-generation workflows at scale.

How to choose

Lowest per-grab rate with full features: Browserless, but you will write Playwright or Puppeteer scripts rather than calling a REST endpoint.
Flat annual billing with no monthly waste: Grabbit.
Widest SDK coverage for non-JS backends: ScreenshotOne.
Enterprise SLAs and long track record: Urlbox.
Simple thumbnails, minimal budget, no features needed: Thum.io.
AI agents or automation pipelines: Grabbit, MCP server included.

For Grabbit's full parameter reference, authentication, and integration guides, see the screenshot API docs.

Originally published on the Grabbit blog.

Visual Regression Testing: A Practical Guide for 2026

Nico Acosta — Wed, 17 Jun 2026 20:52:25 +0000

A functional test confirms the checkout button submits the form. It will not tell you the button is now white on white, overlapping the price, or pushed off the screen on mobile. That is what visual regression testing catches: the layout and styling breakage that passes every assertion and still ships a broken page.

What is visual regression testing?

Visual regression testing captures screenshots of your interface, compares each new capture against an approved baseline, and flags the pixels that changed. Instead of asserting on the DOM, you assert on what the user actually sees. A change that moves an element, shifts a color, or breaks a responsive layout shows up as a visual diff even when every functional test stays green.

How the workflow works

The loop is the same across every tool:

Capture a baseline. Screenshot the page or component in a known state and store the image.
Capture on change. On each pull request or deploy, capture the same view again.
Diff. Compare the new capture to the baseline pixel by pixel (or perceptually).
Review. If the diff is over your threshold, the test fails and a person looks at it.
Approve or fix. If the change was intended, approve it as the new baseline. If not, it is a bug you just caught before users did.

Why visual tests get flaky (and how to fix it)

The reason teams abandon visual testing is flakiness: tests that fail on changes nobody made. Almost every false positive traces back to an inconsistent capture, not a real regression. The usual culprits:

Animations and transitions captured mid-flight.
Lazy-loaded images or client-rendered content that had not finished when the shot was taken.
Web fonts that loaded a frame late, shifting text.
Dynamic data (timestamps, names, A/B variants) that differs every run.
A different viewport between baseline and comparison.

The fix is to make capture deterministic: pin the viewport width, wait for the page to settle before capturing, freeze animations, and use stable seed data. Consistency in the capture step is what separates a visual suite people trust from one they mute.

The tools

Playwright has toHaveScreenshot, which captures and diffs against a stored baseline in a single assertion. The easiest start if you already run Playwright.
Storybook plus a test runner is a strong fit for component libraries, testing each component in isolation.
Hosted services like Percy and Applitools add a review UI, baseline management, and cross-browser rendering on top of the diff.
BackstopJS is a long-standing open-source option for page-level scenarios.

Pick the one that matches how you already build. The capture-and-diff loop is identical underneath. For a fuller rundown of open-source and SaaS options, see the best visual regression testing tools.

The capture layer: consistent screenshots

Every visual regression tool needs one thing to be reliable: a screenshot that looks the same every time, given the same input. When you are testing deployed URLs (staging, preview deploys, production canaries) rather than local components, a screenshot API gives you that consistent capture without running and scaling headless browsers in CI.

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

Pinning width keeps the layout identical between runs, full_page captures the whole document, and delay_ms waits for content to settle so lazy-loaded sections do not cause false diffs. Store the returned image_url as your baseline, capture again on each deploy, and diff the two. For running these captures on a schedule or across many URLs, see automated screenshots, and for every capture option see the screenshot API.

Where to start

If you already use Playwright, add one toHaveScreenshot assertion to your most important page and watch it for a week. If you test deployed URLs, capture consistent baselines with an API and diff them in CI. Either way, start with a handful of high-value screens, get the captures deterministic, and expand once the suite is quiet enough to trust.

Originally published on the Grabbit blog.

How to Take a Full-Page Screenshot (Every Method That Works in 2026)

Nico Acosta — Wed, 17 Jun 2026 17:49:00 +0000

A regular screenshot stops at the fold: it captures only what is currently on your screen. A full-page screenshot captures the entire document, from the top of the page to the bottom, no matter how far it scrolls. Here is how to do it on every platform, plus how to capture full pages automatically when you need more than one.

The header image above was captured from grabbit.live with the Grabbit API.

The quickest answer per platform

Platform	Fastest method
Chrome	DevTools Command Menu, "Capture full size screenshot"
Firefox	Right-click, "Take Screenshot", "Save full page"
Edge	Web capture (Ctrl+Shift+S), "Capture full page"
Windows	Use the browser methods above (Snipping Tool is viewport only)
Mac	Use the browser methods above (no native scroll capture)
iPhone	Screenshot, then the "Full Page" tab, save as PDF
Android	Screenshot, then "Capture more"

Chrome (built in, no extension)

Chrome can capture a full page without any add-on:

Open the page and press F12 to open DevTools.
Open the Command Menu with Ctrl+Shift+P (Cmd+Shift+P on Mac).
Type screenshot and choose Capture full size screenshot.

Chrome scrolls the page for you and saves one tall image to your downloads. This is the most reliable manual method on any operating system, since it works the same on Windows, Mac, and Linux.

Chrome and Edge with an extension

If you take full-page shots often, a one-click extension is faster. GoFullPage and similar extensions add a toolbar button that scrolls, stitches, and exports the page as PNG or PDF. Useful for occasional manual captures, though every extension you install gets access to the pages you visit, so weigh that against convenience.

Firefox (built in)

Firefox has a native full-page tool:

Right-click anywhere on the page.
Choose Take Screenshot.
Click Save full page.

Edge (built in)

Microsoft Edge ships Web Capture:

Press Ctrl+Shift+S, or open the menu and choose Web capture.
Choose Capture full page.
Annotate if you want, then save.

Windows and the Snipping Tool

A common question: can the Snipping Tool take a scrolling screenshot? No. The Windows Snipping Tool and PrtScn only capture the visible area. For a full page on Windows, use Chrome's DevTools capture, Edge's Web Capture, or an extension.

Mac

macOS shortcuts (Cmd+Shift+3 for the whole screen, Cmd+Shift+4 for a selection, Cmd+Shift+5 for the toolbar) all capture only what is visible. There is no native scrolling-screenshot tool, so for a full page use your browser's built-in capture as described above.

iPhone and Android

iPhone: take a screenshot (side button plus volume up), tap the preview thumbnail, then switch to the Full Page tab at the top. Save the entire page as a PDF.
Android: take a screenshot, then tap Capture more (the exact label varies by manufacturer) to extend the capture down the page.

Capturing full pages automatically with an API

Manual methods are fine for one page. When you need to capture full pages on a schedule, across many URLs, or inside an app, an API does it with a single request. Set full_page to true and the capture spans the entire document height:

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

The response returns a hosted image_url for the full page. Add delay_ms (up to 10000) to wait for lazy-loaded content, width (320 to 1920) to set the layout, or a CSS selector to clip to one element. For the full walkthrough, see the full-page screenshot guide, and for every parameter see the screenshot API. If you only need a normal capture, our guide to screenshotting any website covers the basics.

Originally published on the Grabbit blog.

Open Graph Image Sizes and Dimensions: The Complete 2026 Guide

Nico Acosta — Tue, 16 Jun 2026 22:19:38 +0000

When you paste a link into Slack, X, or iMessage and it unfurls into a rich card with a big image, that image comes from your page's Open Graph tags. Get the size wrong and the card collapses into a tiny thumbnail or, worse, shows nothing at all. This guide gives you the exact dimensions and the meta tags to use.

The short answer

Use 1200 by 630 pixels. That is an aspect ratio of roughly 1.91 to 1, and it is the size every major platform renders as a full-width preview card. If you only remember one number, remember 1200 by 630.

Platform-by-platform sizes

Platform	Recommended size	Notes
Facebook	1200 x 630	Under 600 x 315 drops to a small thumbnail
X (Twitter)	1200 x 630	Needs `twitter:card` set to `summary_large_image`
LinkedIn	1200 x 627	Treats 1200 x 630 the same in practice
Slack	1200 x 630	Reads standard `og:image`
Discord	1200 x 630	Reads standard `og:image`
iMessage	1200 x 630	Reads standard `og:image`

The takeaway: one 1200 by 630 image satisfies all of them. You do not need a different file per platform.

Minimum, maximum, and file size

Minimum for a large card: 600 by 315. Below this, Facebook and LinkedIn render a small square thumbnail next to the text instead of the big card.
Aspect ratio: keep it at 1.91 to 1. If your image is a different ratio, platforms crop it, usually from the center, and your text can get cut off.
File size: keep it under 8 MB for Facebook, but aim for well under 1 MB so the card loads fast. WebP or optimized PNG and JPEG all work.
Safe zone: keep important text and logos away from the outer edges, since some apps crop a few pixels.

The meta tags you actually need

Put these in the <head> of every page you want to share:

<meta property="og:title" content="Your page title" />
<meta property="og:description" content="A one-line summary." />
<meta property="og:image" content="https://yoursite.com/og/your-page.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://yoursite.com/og/your-page.png" />

Setting og:image:width and og:image:height is the detail most people skip. It lets the platform reserve the right space and render the large card immediately instead of guessing.

How to generate OG images from a URL

Designing a unique image for every page by hand does not scale. The pattern that does: build one small HTML template that renders the title and your branding, then capture that page as an image at 1200 by 630.

A screenshot API turns that into a single request. Point it at your template URL with a fixed viewport:

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

The response gives you a hosted image_url you can drop straight into your og:image tag. Because the source is a real web page, you can style it with the same CSS as the rest of your site, pull in dynamic titles, and never open a design tool. This is exactly what Grabbit's screenshot API is built for, and you can wire it up with a free test key first.

Common mistakes

Using a logo as the OG image. Logos are square and get cropped or shrunk. Use a 1200 by 630 card with the title.
Forgetting summary_large_image for X. Without it, X shows the small card no matter how big your image is.
A relative image URL. og:image must be an absolute URL, including https://. Crawlers do not resolve relative paths.
Not testing. Always preview the card before you publish. See the FAQ for how.

Wrapping up

One size, 1200 by 630, covers every major platform. Set the width and height tags, use an absolute URL, add summary_large_image for X, and generate the image from an HTML template so it scales across your whole site. For automating that last step, see how to generate dynamic OG images from any URL.

Originally published on the Grabbit blog.