DEV Community: Grabbit

Screenshot API Alternatives: An Honest Comparison (2026)

Nico Acosta — Wed, 12 Aug 2026 11:39:27 +0000

If you are comparing screenshot API alternatives, you have almost certainly hit one of three walls: a monthly quota that resets before you use it, a feature the tool does not have, or an integration path that does not fit how you actually build. This is an honest, side-by-side comparison of the main options, with a clear note on where each one wins.

The short answer

Every screenshot API does the same core job: send a URL, get back a rendered image. They differ on three things that actually matter, so pick by whichever is your bottleneck:

Billing model. Monthly plans reset unused capacity; a flat annual plan does not. This is the biggest hidden cost for spiky or seasonal workloads.
Per-grab rate. Browserless and Thum.io list the lowest rates. Neither is a one-call REST endpoint for every feature, so cheap-per-grab comes with a trade-off.
Integration. A raw REST endpoint, a first-party SDK for your language, or an agent-callable MCP tool are three different developer experiences.

Grabbit is the alternative when monthly waste and agent onboarding are your pain: $0.002 per capture, 25,000 prepaid credits per year that never reset or expire, plus a built-in MCP server. It is not the cheapest option overall, and this post says so plainly below.

How the alternatives compare

Prices verified June 2026 from each provider's public pricing page, normalized to roughly 10,000 grabs per month. "Included" is each provider's entry-plan allowance. The honest caveat up front: two providers list a lower per-grab rate than Grabbit.

Provider	Per grab	Billing	Included	Monthly waste	Agent
Grabbit	$0.002	Annual flat	25,000 / yr	None	One-line + MCP
ScreenshotOne	$0.0079	Monthly	2,000 / mo	Resets	MCP
Urlbox	$0.0066	Monthly	2,000 / mo	Resets	None
ApiFlash	$0.0035	Monthly	1,000 / mo	Resets	None
ScrapingBee	$0.0049 †	Monthly	~10,000 / mo	Resets	MCP
Browserless	$0.0013 ‡	Monthly	20,000 units / mo	Resets	MCP
Thum.io	$0.0002	Usage metered	$1–$20 / mo min.	Minimum spend	None

† ScrapingBee is credit-based (roughly 25 credits per screenshot grab). ‡ Browserless bills in units (roughly 1 unit per grab) and is a managed browser you drive with your own scripts, not a one-call REST endpoint.

Browserless and Thum.io are cheaper per grab. The trade-offs are real: Browserless is a headless browser you drive with Puppeteer or Playwright, so you still write and maintain the capture code, and Thum.io has a narrow feature set (no full-page capture, no wait controls, no selector targeting). If raw per-grab price is the only thing you care about, one of those two is the honest recommendation, not Grabbit.

Match the alternative to the pain

If monthly resets are wasting money

On a monthly reset plan, a team that captures 1,500 pages in January and 9,000 in March pays the full monthly allowance both months, and January's unused capacity evaporates. You pad the plan to cover the busy month and forfeit the difference every quiet one. Flat annual prepaid credits remove that pressure: you buy a block once, it covers actual usage, and nothing expires at the end of a cycle. For variable workloads (OG images on publish, monitoring runs, batch research), the billing model often matters more than the headline rate. See why monthly screenshot quotas waste money for the full math.

If you need a first-party SDK

ScreenshotOne maintains client libraries for Ruby, PHP, Go, Java, C#, and more. If you want a supported SDK in your language rather than a raw HTTP call, that is a genuine advantage and a good reason to stay with it. Grabbit is a plain REST endpoint plus an MCP server, not a per-language SDK set.

If an AI agent needs to see the page

Most screenshot APIs were designed before agent frameworks existed: you get an API key and call the endpoint from backend code, which means custom glue for every agent that needs visual data. Grabbit and ScreenshotOne both ship an MCP server, so an agent registers capture as a callable tool and gets back a hosted image_url with no glue code. If agent onboarding is why you are shopping, prefer a provider with a one-line or MCP path over a REST-only endpoint.

If you just want the lowest possible rate

Browserless ($0.0013) or Thum.io ($0.0002). Accept that Browserless means writing your own browser scripts and Thum.io means a thin feature set. That is the trade you make for the lowest number in the table.

Try an alternative before you pay

You can wire up Grabbit and run it in CI before adding a card. Every account gets a test key (sk_test_...) that returns a placeholder image at no charge; switch to a live key (sk_live_...) for real captures. Here is a real request against Grabbit's API:

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": true
  }'

The response includes image_url (the hosted screenshot), bytes, execution_ms, and id. Set full_page: false with a fixed height (240 to 1080) for a viewport shot, add delay_ms (up to 10000) to wait for JavaScript-heavy content, or selector to clip to a single element. Point at a sk_test_ key first, so migrating an existing integration costs nothing to prototype.

How to choose

Monthly reset waste, variable volume: Grabbit (flat annual, no reset).
Lowest per-grab rate, willing to script: Browserless.
Simple thumbnails, minimal budget: Thum.io.
First-party SDKs for a non-JS backend: ScreenshotOne.
An AI agent needs to call it: Grabbit or ScreenshotOne (both ship MCP).

If your comparison is really "managed cloud browser vs. a screenshot endpoint," see the Browserbase alternative breakdown. For a wider field than this table, read our honest comparison of the best screenshot APIs. For Grabbit's pricing, parameters, and agent onboarding, see screenshots as a service.

Originally published on the Grabbit blog.

Browserbase Alternative: When You Need a Screenshot, Not a Whole Cloud Browser

Nico Acosta — Mon, 10 Aug 2026 11:43:50 +0000

If you are searching for a Browserbase alternative, the first question worth asking is not "which vendor," it is "do I actually need a cloud browser?" Browserbase gives your code a full, programmable Chrome running in the cloud: persistent sessions, live interaction, stealth, the works. That is the right tool when you are driving a browser through multi-step flows. It is a lot of machinery when all you needed was a picture of a page.

This is an honest comparison, including an explicit section on when you should stay on Browserbase.

The short answer

Browserbase is cloud browser infrastructure for AI agents and automation: you open a session, connect over CDP or an SDK, and operate a real browser remotely. It is built to run whole interaction flows, and it bills accordingly (by session and concurrency).

If your job is narrower, capture a rendered screenshot of a URL, then a screenshot API is the simpler and usually cheaper alternative. You send one request with a URL and get back a hosted image. There is no session to open, keep alive, or tear down.

Grabbit is that alternative when the job is a screenshot: $0.002 per capture on flat prepaid credits that never reset or expire monthly, plus a built-in MCP server so an agent can call it as a tool. Grabbit is not a cloud browser and does not pretend to be one, and this post says plainly below when Browserbase is the correct choice.

Two different jobs that look similar

The reason "Browserbase alternative" is a confusing search is that a screenshot and a browser session look related but are different jobs:

A cloud browser is a live, stateful thing. You navigate, click, type, wait, read the DOM, maybe hand control to a human. You are operating the page. Browserbase, Browserless, Hyperbrowser, Anchor Browser, and Steel all sell this.
A screenshot API is a stateless request. You name a URL and how you want it rendered, and you get an image. You are observing the page, not operating it.

Most of the "Browserbase alternatives" you will find in a SERP are other cloud browsers, which makes sense if you truly need to drive a browser. But a large share of the traffic to that search is people who reached for a cloud browser because they thought a screenshot required one. It does not.

How they compare for the screenshot job

Scoped to "I need a rendered image of a URL," not to full browser automation. Cloud-browser pricing is session or minute based, so a per-grab comparison is only fair for the capture use case. Prices verified August 2026 from each provider's public pricing page.

Tool	What it is	Billing shape	Best when
Grabbit	Screenshot API	Per grab ($0.002), flat prepaid	You need a rendered image of a URL
Browserbase	Cloud browser	Per session / concurrency	You drive a real browser through steps
Browserless	Cloud browser + REST screenshot	Per unit / monthly	You want full control and self-host options
Hyperbrowser	Cloud browser (containers)	Per session / monthly	Lightweight isolated sessions, CAPTCHA handling

The honest read: if you need persistent sessions and live interaction, do not pick a screenshot API, pick a cloud browser. If you need a picture of a page, do not rent a whole browser to take it. Grabbit is also not the cheapest screenshot API in the field; Browserless and Thum.io list lower per-grab rates. Grabbit's edge is the fit and the billing model, prepaid credits that never expire, not a bottom-of-market rate. For the wider field of screenshot APIs specifically, see our honest comparison of the best screenshot APIs.

Why the billing shapes differ

This is the part that makes the cost comparison feel unfair until you see it: you are paying for different things.

A cloud browser holds a real Chrome open for you. You pay for the time that browser is alive and for how many you run at once, because keeping browsers healthy at concurrency is the expensive, hard part (memory creep, restart storms, sticky workers). That cost is real and Browserbase absorbs it so you do not lose weekends to it.

A screenshot API runs the render, uploads the image, and is done. There is no session to keep warm between calls, so it bills per capture. For a workload that is "render this URL, give me the image," paying for session time is paying for a capability you are not using.

Try it before you commit

You can wire up Grabbit and run it in CI before adding a card. Every account gets a test key (sk_test_...) that returns a placeholder image at no charge; switch to a live key (sk_live_...) when you want real captures. Here is a real request against Grabbit's API:

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

The response includes image_url (the hosted screenshot), bytes, execution_ms, and id. Use full_page: true for a scrolling capture, delay_ms (up to 10000) to wait for JavaScript-heavy content to settle, or selector to clip to a single element. Because test captures are free placeholders, prototyping the swap from a cloud-browser screenshot call to Grabbit costs nothing.

For AI agents

Many people arrive at Browserbase because an agent needs to work with the web, and "the agent needs the web" gets rounded up to "the agent needs a whole browser." Sometimes it does: if the agent clicks, types, and navigates across steps, that is a cloud-browser job and Browserbase (or an agent framework on top of it) is the right call.

But a large slice of agent-web work is just seeing a page: feed the rendered view into a vision step, verify your own frontend, or ground the model in what a URL actually looks like. For that, a screenshot API is the lighter path. Grabbit ships an MCP server, so the agent registers capture as a callable tool and gets back a hosted image_url to pass downstream, with no browser session to manage. For the agent-eyes use case in depth, see screenshots for AI agents.

When to stay on Browserbase

An honest comparison names when not to switch:

You need multi-step interaction. Logging in, filling forms, clicking through a flow, reading the DOM between steps. A screenshot API captures a page; it cannot operate one.
You need persistent, authenticated sessions. Holding a logged-in browser open across calls is exactly what a cloud browser is for.
You use an interactive agent framework. Tools like Stagehand drive a real browser. A screenshot endpoint is not a substitute.
You need live takeover or stealth. Human-in-the-loop control and advanced anti-bot handling are cloud-browser features, not screenshot-API features.

Grabbit's pitch is not "we replace Browserbase." It is narrower and honest: if the job is a screenshot, you do not need a whole cloud browser to take it, and paying per session for a per-image job is waste.

How to choose

You need a rendered image of a URL: a screenshot API (Grabbit, or a cheaper-per-grab option if raw rate is all that matters).
You drive a browser through multi-step flows: stay on Browserbase.
You want a cloud browser but with self-host options: Browserless.
Your agent needs to see, not operate, a page: Grabbit (one call + MCP).
Your agent needs to click and navigate: Browserbase or an interactive framework.

For Grabbit's pricing, parameters, and agent onboarding, see the screenshot API page. To schedule captures without running any browser yourself, see screenshot automation.

Originally published on the Grabbit blog.

Why Monthly Screenshot Quotas Waste Your Money (Screenshot API Pricing, Explained)

Nico Acosta — Sun, 09 Aug 2026 11:42:15 +0000

If you are comparing screenshot API pricing, the pricing pages all look roughly the same: a few tiers, a monthly price, a screenshot quota per tier, and overage per extra capture. The number that decides your real cost is not on the card. It is the quota that resets every month, and how much of it you actually use. On a spiky workload, a monthly reset plan makes you pay for a peak you hit occasionally and forfeit the rest. This post explains the mechanic, then shows how to read a pricing page so you buy captures instead of empty allowance.

The short answer

Most screenshot APIs bill a fixed monthly subscription with a reset quota: you pay for, say, 2,000 captures a month whether you make 2,000 or 200, and next month the counter goes back to zero. That model is fine when your usage is steady. It quietly wastes money when your usage is spiky, which screenshot workloads almost always are.

The waste is the gap between what you provision and what you use. To cover an occasional busy month you size up your plan, then forfeit the unused allowance in every quiet month. The sticker price hides that gap.

Grabbit takes the other approach: $50 per year for 25,000 prepaid captures ($0.002 each) that never reset or expire monthly. Grabbit is not the cheapest screenshot API on headline price, and this post is explicit about that below. The point here is the pricing model, not a rock-bottom rate.

How screenshot API pricing usually works

Walk a typical pricing page and you will see one of three billing models:

Monthly subscription with a reset quota (the common one). A tier bundles a fixed number of captures per month. Unused captures do not roll over. Go over and you pay overage per extra grab, or get blocked until next cycle. This is what most listings on a "screenshot api pricing" search use.
Usage metered. You pay per request with a small monthly minimum. No quota to waste, but the minimum spend is its own small floor, and metered plans often have a thinner feature set.
Prepaid credits. You buy a block of captures once. They draw down as you use them and do not expire on a monthly boundary. Grabbit sells these on a flat annual plan.

The three models can show nearly identical per-grab math on paper and produce very different bills, because the reset quota charges you for allowance, not for work done.

Why a reset quota wastes money on spiky workloads

Screenshot volume is rarely a flat line. The real pattern looks like bursts:

A batch of Open Graph images generated the day you publish a dozen posts.
A visual monitoring run that fires on a schedule, then nothing until the next one.
A one-off research crawl capturing a list of competitor pages, then quiet.
An agent pipeline that captures heavily during a task and idles between tasks.

Put concrete numbers on it. Say you capture 1,500 pages in January, 9,000 in March, and a few hundred most other months. To not get blocked in March, you provision a plan sized for roughly 9,000 captures a month. In January you pay for that whole allowance and use a sixth of it. Every quiet month, you pay for thousands of captures you never make. Over a year, the forfeited allowance can dwarf the cost of the captures you actually took.

That is the mechanic. A reset quota bills your peak every month and hands you nothing back for the troughs. The lower the ratio of your average month to your busiest month, the more a monthly plan overcharges you.

Prepaid credits invert it: you buy a block once, draw it down at your real pace, and the busy month and the quiet month both bill only the captures you made. For variable capture volume, the billing model usually matters more than a fraction of a cent on the per-grab rate.

The honest caveat: cheapest sticker price is not Grabbit

A "screenshot api pricing" search is full of pages claiming the lowest number, so here is the honest version. Grabbit is not the cheapest screenshot API by headline price. Some providers advertise entry plans from $5 to $9 per month, and on raw per-grab rate Browserless ($0.0013) and Thum.io ($0.0002) both list lower numbers than Grabbit's $0.002.

The trade-offs behind those lower numbers are real: Browserless is a managed headless browser you drive with your own Puppeteer or Playwright scripts rather than a single REST call, and Thum.io has a limited feature set (no full-page capture, no wait controls, no selector targeting). If the only thing you care about is the lowest per-grab rate and you are willing to script, one of those is the honest pick, not Grabbit.

Grabbit's claim is narrower: flat annual billing with zero monthly reset waste, and one-line agent onboarding. If your pain is a quota you keep forfeiting, that is the thing that saves you money, not the sticker price. Prices here were verified June 2026 from each provider's public pricing page, normalized to roughly 10,000 grabs per month.

Why "temporary need" is the category's real pricing problem

There is a deeper reason the reset-quota model fits this category badly. The screenshot API market skews toward temporary needs: a project that ends, a marketing job that ships, a migration that finishes. When the market leader ScreenshotOne was publicly torn down in 2026, the founder said the category's core problem in the open: there is no single ICP it can scale with, and customers churn because the need was temporary. A monthly subscription is the worst possible fit for a temporary need, you keep paying after the work is done until you remember to cancel.

Prepaid credits that never expire suit a temporary-or-spiky need better: you buy what the job needs, use it when the job runs, and nothing keeps billing you between jobs. (Whether that changes long-run retention is a separate question we are not claiming to have answered, it is a better fit for the buying pattern, full stop.)

How to read a screenshot API pricing page

When you land on a pricing page, get past the sticker price and check five things:

Reset or roll over? Does unused quota carry forward, or evaporate at the cycle boundary? This is the single biggest driver of real cost on spiky usage.
Effective cost per capture you make. Divide the plan price by the captures you realistically make in an average month, not by the quota. That is your true per-grab cost.
Overage behavior. Do you pay per extra grab, or get hard-blocked until next cycle? A hard block can break a publish or a monitoring run at the worst moment.
What the free tier excludes. Free plans often gate full-page capture, custom viewports, or output formats. Confirm the free number is a real preview of the paid product, not a stripped-down one.
Feature parity across tiers. Some providers put the parameters you need (selector targeting, wait delays, WebP) behind a higher tier, so the cheap plan cannot actually do your job.

Test the integration before you pay a cent

You do not have to guess. Grabbit gives every account a test key (sk_test_...) that returns a placeholder image at no charge, so you can wire up the API and run it in CI before adding a card. Switch to a live key (sk_live_...) when you want real captures. Here is a real 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,
    "height": 720,
    "format": "webp",
    "full_page": true
  }'

The response includes image_url (the hosted screenshot), bytes, execution_ms, and id. Add delay_ms (up to 10000) to wait for JavaScript-heavy content, or selector to clip to a single element. Point at a sk_test_ key first: test captures are free placeholders, so proving out an integration costs nothing.

How to choose

Spiky or seasonal volume, quota waste is your pain: a flat prepaid plan like Grabbit (no monthly reset).
Steady, predictable monthly volume: a monthly subscription wastes nothing, and the per-grab math is what it is.
Lowest per-grab rate, willing to write scripts: Browserless.
Simple thumbnails, minimal budget: Thum.io.
Low, flat volume and you enjoy owning infra: self-host Puppeteer or Playwright.

For a full field comparison, see our honest comparison of the best screenshot APIs and the head-to-head ScreenshotOne alternative breakdown. If an agent is what needs to capture pages, the screenshots for AI agents guide covers the integration path. For Grabbit's pricing, parameters, and onboarding, see screenshots as a service.

Originally published on the Grabbit blog.

Open Graph Meta Tags: The Complete Reference (Every Tag, With Examples)

Nico Acosta — Sat, 08 Aug 2026 11:41:15 +0000

Open Graph meta tags are the snippets in your page's <head> that control how a link looks when someone shares it. Get them right and your URL unfurls into a rich card with a title, a summary, and an image. Miss them and the same link shows up as bare text. This is the complete reference: every tag worth setting, what each one does, and copy-paste examples.

The short answer: five tags

Most pages need exactly five Open Graph tags. Put these in the <head>:

<meta property="og:title" content="Your page title" />
<meta property="og:description" content="A one-line summary of the page." />
<meta property="og:image" content="https://yoursite.com/og/your-page.png" />
<meta property="og:url" content="https://yoursite.com/your-page" />
<meta property="og:type" content="website" />

Facebook, LinkedIn, Slack, Discord, iMessage, and WhatsApp all read these. Set them and your link previews work almost everywhere. The rest of this reference covers the optional tags and the X-specific ones.

The required tags, one by one

These five carry the card. Skip any of them and the preview degrades.

Tag	What it does
`og:title`	The headline of the card. Independent of the `<title>` element.
`og:description`	The summary line under the title. One or two sentences.
`og:image`	The picture in the card. Absolute URL, 1200 by 630 for the large card.
`og:url`	The canonical URL of the page, without tracking parameters.
`og:type`	The category: `website`, `article`, `video.movie`, and so on.

A few details that trip people up:

og:title is not your <title>. They can match, but og:title lets you write a version tuned for sharing. Keep it under about 60 characters so it does not truncate.
og:url should be the canonical URL. Use the clean permanent address, not the one with ?utm_source=... on it, so every share collapses to the same object.
og:image must be an absolute https:// URL. A relative path like /og.png will not resolve for the crawler. It also has to be publicly reachable: if the image needs a login, the card shows nothing.

The image tags that make the large card render

og:image alone works, but three companion tags make the difference between a big card and a small thumbnail:

<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 property="og:image:alt" content="A short description of the image" />

Declaring og:image:width and og:image:height lets the platform reserve the right space and render the large card immediately instead of guessing the dimensions on first fetch. Use 1200 by 630 pixels, the size every major platform treats as the full-width preview. og:image:alt is the accessibility description, read by screen readers on platforms that expose it.

The optional tags worth setting

Beyond the core five, a handful of tags add polish and matter for specific og:type values:

<meta property="og:site_name" content="Your Brand" />
<meta property="og:locale" content="en_US" />

og:site_name is the name of the overall site, shown as a small label on some cards (LinkedIn, for instance). Set it once to your brand.
og:locale declares the language and region, like en_US or fr_FR. Useful if your pages are localized.

When og:type is article, these structured tags become relevant and show up on news and blog cards:

<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-08-08T09:00:00Z" />
<meta property="article:author" content="https://yoursite.com/authors/jane" />
<meta property="article:section" content="Engineering" />
<meta property="article:tag" content="open graph" />

You only need the article:* tags on pages that are genuinely articles. For a marketing page or a landing page, og:type of website and the core five are enough.

X (Twitter) tags: what you actually need

X reads its own twitter: tags but falls back to your og: tags when they are absent. The one tag you should always set is twitter:card:

<meta name="twitter:card" content="summary_large_image" />

Without summary_large_image, X renders a small square thumbnail beside the text instead of the big image card. Note the attribute difference: og: tags use property=, while twitter: tags use name=.

You can stop there. X will pull the title, description, and image from og:title, og:description, and og:image. Only add these if you want a different headline or image on X than everywhere else:

<meta name="twitter:title" content="A headline tuned for X" />
<meta name="twitter:description" content="A summary tuned for X." />
<meta name="twitter:image" content="https://yoursite.com/og/your-page.png" />

A complete, copy-paste example

Here is the full <head> block for a typical article page, combining everything above:

<head>
  <title>Open Graph Meta Tags: The Complete Reference</title>

  <!-- Open Graph -->
  <meta property="og:title" content="Open Graph Meta Tags: The Complete Reference" />
  <meta property="og:description" content="Every og: tag worth setting, with examples." />
  <meta property="og:image" content="https://yoursite.com/og/reference.png" />
  <meta property="og:image:width" content="1200" />
  <meta property="og:image:height" content="630" />
  <meta property="og:url" content="https://yoursite.com/blog/og-meta-tags" />
  <meta property="og:type" content="article" />
  <meta property="og:site_name" content="Your Brand" />

  <!-- X (Twitter) -->
  <meta name="twitter:card" content="summary_large_image" />
</head>

How to generate the og:image from a URL

Writing the tags is the easy part. The hard part is producing a unique, on-brand og:image for every page without designing one by hand. The pattern that scales: build one HTML template that renders the page title and your branding, then capture that template 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, and get back a hosted image you can drop straight into og:image:

curl -X POST https://grabbit.live/api/v1/grabs \
  -H "Authorization: Bearer sk_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yoursite.com/og-template?title=Your+Post+Title",
    "width": 1200,
    "height": 630,
    "format": "png"
  }'

The response includes the hosted image URL. Set og:image to it, and every page gets its own preview card generated from real HTML, no design tool required. This is the same approach behind dynamic OG images in Next.js and any other framework: render a URL, screenshot it, ship the result.

For the deeper background on why the image matters and how platforms crop it, see what an OG image is. Once your tags are live, run the page through an OG image checker to confirm the crawler sees what you expect, and if a preview looks wrong, an Open Graph debugger shows you the exact tags each platform scraped.

Grabbit is a screenshots-as-a-service API built for exactly this job: point it at a URL, get back a hosted image, no headless browser to run. Live grabs are a flat $0.002 each on prepaid credits that never expire, and a test key renders free placeholders so you can wire up your OG pipeline before adding a card. See the screenshot API for the full reference.

Common mistakes

Injecting og: tags with client-side JavaScript. Crawlers run little to no JS, so they see an empty <head>. Server-render your meta tags.
A relative og:image path. It must be an absolute https:// URL, or the image will not resolve.
Forgetting twitter:card. Without summary_large_image, X shows a small thumbnail instead of the large card.
Not clearing the cache after a fix. Platforms cache the scrape. Use each platform's debugger to force a re-scrape once you have corrected a tag.

Originally published on the Grabbit blog.

Selenium vs Playwright: Which Should You Use in 2026?

Nico Acosta — Fri, 07 Aug 2026 11:42:57 +0000

Playwright and Selenium are the two tools most teams weigh when they automate a browser, and in 2026 the momentum is clearly with Playwright: it just passed Selenium in adoption surveys for the first time. But "which is winning" and "which should you use" are different questions. The right answer depends on your language, your existing suite, and whether you are automating tests or just need an image back from a URL. Here is the honest comparison.

The short answer

New project, JavaScript or TypeScript or Python: Playwright. Auto-waiting, a smaller API, and three bundled browser engines make it the faster path to reliable automation.
Existing enterprise Selenium suite, or a non-JS ecosystem (Java, C#, Ruby): Selenium is still a reasonable default. The WebDriver standard, the language breadth, and the grid ecosystem are hard to walk away from.
You need cross-browser tests with the least flakiness: Playwright. One API drives Chromium, Firefox, and WebKit, and auto-waiting removes most timing bugs.
You just need a screenshot of a URL, not a test framework: neither. A hosted screenshot API returns a hosted image from one request, with no browser to run.

The rest of this post shows where the two actually differ so you can decide with the details.

Architecture: WebDriver vs direct control

The core difference is how each tool talks to the browser.

Selenium drives browsers through the W3C WebDriver protocol. Your script sends commands to a driver (chromedriver, geckodriver), which relays them to the browser over HTTP. That standardization is Selenium's superpower and its tax: it works with almost any browser and language, but every command is a separate round trip.

Playwright talks to the browser over a single persistent connection using the browser's own debugging protocol. Fewer round trips, and it can observe the page state directly, which is what makes auto-waiting possible.

This one design choice explains most of the practical differences below: speed, waiting, and reliability all trace back to it.

Language and browser support

This is where Selenium still leads.

	Selenium	Playwright
Languages	Java, Python, C#, Ruby, JavaScript, and more	JavaScript/TypeScript, Python, Java, C#
Browsers	Chrome, Firefox, Edge, Safari (real installs) + huge grid/cloud ecosystem	Bundled Chromium, Firefox, WebKit
Standard	W3C WebDriver	Browser debug protocol (not a standard)

If your team is on Ruby, or you must drive a specific real browser build on a specific OS through a cloud grid, Selenium's breadth wins. If you want three engines that cover the matrix most apps care about, with zero driver management, Playwright's bundled browsers are simpler.

Note that "WebKit" in Playwright is the engine behind Safari, not Safari itself, so it is a very close approximation rather than a byte-for-byte Safari render.

Auto-waiting: Playwright's biggest day-to-day win

Flaky tests are almost always timing bugs. An element is not clickable yet, or the network has not settled, and a fixed sleep either wastes time or fails intermittently.

Selenium makes you manage this. The recommended pattern is an explicit wait:

const { Builder, By, until } = require('selenium-webdriver');

const driver = await new Builder().forBrowser('chrome').build();
await driver.get('https://example.com/login');
await driver.wait(until.elementLocated(By.css('#submit')), 5000);
await driver.findElement(By.css('#submit')).click();
await driver.quit();

Playwright waits for you. Its locators auto-wait for the element to be attached, visible, and actionable before acting, so the same flow needs no explicit wait:

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

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com/login');
await page.locator('#submit').click();
await browser.close();

Across a full suite, deleting hundreds of wait and sleep calls is the single biggest reliability and maintenance improvement teams report after migrating.

Speed

Playwright is generally faster, and the architecture explains why. Selenium's per-command HTTP round trips add up over a long test, and explicit waits are often padded to be safe. Playwright's single connection and auto-waiting mean it acts as soon as the page is ready, not after a fixed delay.

The gap is real on multi-step flows. On a single screenshot it is mostly noise, because page load time dominates and both tools spend that time the same way.

Locators: role and text over XPath

Selenium's world is CSS and XPath selectors tied to the DOM structure. That works, but a renamed class or an extra wrapper div breaks the locator.

Playwright still supports CSS and XPath, but pushes you toward user-facing locators that read the accessibility tree:

// Playwright: resilient, user-facing locators
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email').fill('user@example.com');
await page.getByText('Welcome back').waitFor();

These survive DOM refactors because they find the button labelled "Submit" rather than its position in the markup. It is a small API difference with a big effect on how often tests break when the frontend changes.

Migrating from Selenium to Playwright

Migration is worth it when flaky tests and explicit-wait upkeep are costing you real time, and your app is JavaScript-heavy. The wait-code deletion alone often pays for the move.

It is not worth it when your Selenium suite is stable, your team lives in a language Playwright serves poorly, or your grid, reporting, and CI are deeply wired into WebDriver. A working suite is an asset; do not rewrite it for fashion.

If you do migrate, do it incrementally: run new tests in Playwright while the Selenium suite keeps guarding old ground, and port flaky tests first, because those are exactly the ones auto-waiting fixes.

Screenshots: where both tools are overkill

Both frameworks take screenshots, and the code is nearly identical. In Selenium:

const image = await driver.takeScreenshot();
require('fs').writeFileSync('page.png', image, 'base64');

In Playwright:

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

But if a screenshot is the only thing you need, either tool is a lot of moving parts. You are installing a driver or a bundled browser, running headless Chromium in your own infrastructure, and owning the parts nobody enjoys:

Provisioning. Headless browsers 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, so a long-lived capture service becomes a browser fleet you keep current.
Concurrency. One browser does one job at a time well. Thousands of captures a day means a pool, a queue, and back-pressure to build and operate.

None of that is test code, and it is the same whether you picked Selenium or Playwright.

The same capture as one API call

When screenshots are a feature you ship rather than a step inside a test, a hosted screenshot API skips the browser entirely. Here is a full-page capture 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 either framework map onto request parameters: fullPage becomes full_page, a locator or selector becomes the selector field, and a manual wait becomes delay_ms (0 to 10000). Width accepts 320 to 1920, height 240 to 1080, and format is png, jpeg, or webp. Pricing is a flat $0.002 per capture on prepaid credits that never reset, so a screenshot you run once a week costs the same per image as one you run a thousand times a day.

Which to choose

Greenfield project, want the least flakiness: Playwright.
Existing enterprise suite, or a non-JS stack, or a specific real-browser grid: Selenium.
Learning automation from scratch in 2026: start with Playwright, add Selenium for enterprise roles.
You just need an image from a URL, not a test framework: skip the browser and call an API.

For the framework-specific deep dives, see taking screenshots in Playwright and taking screenshots in Selenium. If you are weighing hosted options, the honest comparison of screenshot APIs covers the trade-offs without the marketing, and Puppeteer vs Playwright compares the two Chromium-first libraries head to head.

Originally published on the Grabbit blog.

How to Run Headless Chrome in Docker for Screenshots (and the Maintenance Tax It Adds)

Nico Acosta — Thu, 06 Aug 2026 11:41:20 +0000

You can run headless Chrome in Docker, and for a controlled workload it is the right call. The catch is that a bare apt install chromium plus chrome --headless does not work: Chrome refuses to start, crashes on big pages, renders text as empty boxes, and leaves zombie processes behind. This guide gives you a Dockerfile that actually runs, explains each flag that makes it work, and names the ongoing maintenance so you can decide whether to run Chrome yourself or hand the render off to an API.

The short answer

To run headless Chrome in a container you need four things the base image does not give you:

Chromium plus its shared libraries (a slim base ships neither).
The right launch flags: --no-sandbox, --disable-gpu, --disable-dev-shm-usage.
Fonts, or every screenshot renders text as boxes.
An init process to reap the zombie Chrome children, plus a non-root user so --no-sandbox is not a gaping hole.

Miss any one and it fails in a way whose error message does not name the real cause. That is the whole reason this problem has a dozen Stack Overflow answers.

A Dockerfile that works

FROM node:20-slim

# Chromium + the shared libs a slim base is missing, fonts, and an init.
RUN apt-get update && apt-get install -y --no-install-recommends \
      chromium \
      fonts-liberation fonts-noto-color-emoji \
      libnss3 libatk-bridge2.0-0 libgbm1 libasound2 \
      tini \
    && rm -rf /var/lib/apt/lists/*

# Run as a non-root user, because we launch with --no-sandbox below.
RUN useradd --create-home chrome
USER chrome
WORKDIR /home/chrome

ENV CHROME_BIN=/usr/bin/chromium

# tini (PID 1) reaps the zombie Chrome children a long-running renderer leaves.
ENTRYPOINT ["tini", "--"]
CMD ["chromium", \
     "--headless=new", \
     "--no-sandbox", \
     "--disable-gpu", \
     "--disable-dev-shm-usage", \
     "--screenshot=/home/chrome/out.png", \
     "--window-size=1280,720", \
     "https://example.com"]

Build and run it, then copy the screenshot out:

docker build -t chrome-shot .
docker run --rm -v "$PWD:/out" chrome-shot \
  chromium --headless=new --no-sandbox --disable-dev-shm-usage \
  --screenshot=/out/out.png --window-size=1280,720 https://example.com

Everything after chrome-shot overrides the CMD, so you can point it at any URL without rebuilding.

What each flag is actually fixing

--no-sandbox is the flag everyone hits first. Chrome's sandbox needs Linux user namespaces and kernel calls that Docker's default seccomp and AppArmor profiles block, so Chrome cannot fork its sandboxed children and exits with a terse Failed to move to new namespace. --no-sandbox skips the sandbox. It is a real security boundary you are removing, which is exactly why the Dockerfile above runs as a non-root chrome user: trusted URLs plus a non-root user keeps the blast radius small.

--disable-dev-shm-usage is the one that bites later, in production, on a page you did not test with. Docker mounts /dev/shm at 64MB by default. Chrome uses that shared-memory region for its render process, and a large or image-heavy page overruns it, crashing the tab with session deleted because of page crash. This flag tells Chrome to write to /tmp instead. The alternative is docker run --shm-size=1gb, but the flag travels with the image, so prefer it.

--disable-gpu avoids the container trying to reach a GPU that is not there. Harmless to keep even where it is no longer strictly required.

--headless=new opts into the modern headless mode (the default implementation since Chrome 112), which is the same browser as headful Chrome, so what you capture matches what a user sees. Older tutorials use bare --headless, which on current Chrome maps to the new mode anyway.

The parts the tutorials skip

The Dockerfile runs. That is not the same as being done, and the gap is where the maintenance tax lives.

Fonts. A slim base image ships no fonts, so text renders as tofu boxes and emoji disappear. You install font packages by hand (fonts-liberation, fonts-noto-color-emoji, and CJK packs if you capture non-Latin pages). Every new script you need to render is another package to remember.
Zombie processes. Chrome spawns child processes, and a long-running container without a real init as PID 1 accumulates defunct entries until the process table is a mess. That is what tini (or dumb-init, or docker run --init) is for.
Memory growth. Chrome's memory climbs over a long-lived process, and under load it does not always come back down. The common production workaround is to restart the renderer on a schedule or after N captures, which is its own moving part to build and watch. This is the exact pain developers describe: Chromium memory leaks forcing you to constantly kill and restart pods.
Patching. A pinned Chromium is a frozen attack surface. Keeping it current means rebuilding the image on Chrome's release cadence, then re-testing that none of the flags above regressed.

None of this is hard once. All of it is forever.

When to hand the render to an API instead

Running Chrome in Docker earns its keep when you want full control of the browser, capture at high volume where per-request cost matters, or need the container for more than screenshots. If all you need is "give me an image of this URL," the container is a lot of standing infrastructure for one HTTP call.

A hosted screenshot API removes the image, the flags, the fonts, the /dev/shm sizing, the zombie reaping, and the restart cron. You send a URL and get a hosted image back:

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

The response is JSON with a hosted image_url you can cache or embed. The same request handles the things the container makes you handle yourself: it waits for the page, sizes the viewport, and captures the full scrolling page when you pass full_page: true. Add delay_ms (0 to 10000) to wait for late-loading content, format (png, jpeg, or webp) to pick the output, or selector to crop to a single element.

Grabbit is prepaid at a flat $0.002 per live grab, and the credits do not reset or expire monthly, so a spiky screenshot workload does not pay for a subscription tier it never fills. Test-environment keys return a placeholder for free, so you can wire it up before adding a card. This is not the cheapest per-grab rate on the market, but it is one HTTP call with no container to keep alive. See the screenshot API for the full parameter reference.

The honest trade is control versus operations. If you want the browser under your own roof, the Dockerfile above is a solid start, and the maintenance failure modes are worth reading up front. If you would rather not run Chrome at all, skipping the container is the point of the API.

Originally published on the Grabbit blog.

Playwright vs Cypress: Which Should You Use in 2026?

Nico Acosta — Wed, 05 Aug 2026 11:41:05 +0000

Playwright and Cypress are both strong end-to-end testing frameworks, and for many projects either one works. The short version: choose Playwright if you need cross-browser coverage (including Safari/WebKit), free parallel execution, or multi-tab and cross-origin flows; choose Cypress if you are a JavaScript-only team building a single-page app and you value its interactive time-travel runner and fast local feedback. This guide walks the real differences, gives a recommendation per project type, and covers the part both tools handle the same way in principle but differently in practice: screenshots.

The short answer

If you want a one-line decision rule:

New project, cross-browser matters, CI-heavy suite → Playwright.
Single-page app, Chromium-only, you want the smoothest local debugging → Cypress.
Team already fluent in one of them, no hard blocker → stay where you are; both are actively maintained.

Everything below is the reasoning behind that rule.

Browser coverage

This is the biggest single difference. Playwright drives Chromium, Firefox, and WebKit natively, so you can run the same test across all three engines, WebKit being the closest practical stand-in for Safari. Cypress is Chrome-family first; it runs in Chromium-based browsers and Firefox, but it has no real WebKit/Safari support.

If "does it work in Safari?" is a question your team has to answer, Playwright answers it and Cypress does not. If you only ship to Chromium users, this difference does not affect you.

Speed and parallelization

Playwright controls the browser out-of-process over the DevTools protocol, while Cypress runs inside the browser's execution loop alongside your app. In practice Playwright tends to run large suites faster, and independent benchmarks put it ahead on raw execution.

The bigger practical gap is parallelization. Playwright shards tests across workers for free, out of the box. Cypress can parallelize too, but its optimal parallel execution and the run dashboard have historically been a paid Cypress Cloud subscription. For a large CI suite, that is a real cost line, not a footnote.

Language support

Cypress is JavaScript and TypeScript only. Playwright supports JavaScript, TypeScript, Python, Java, and .NET. If your backend team writes tests in Python or your org standardizes on C#, Playwright lets them share one tool. For a pure JS/TS shop this is a non-issue.

Multi-tab, multiple origins, and iframes

Cypress runs in a single-origin browser sandbox. That design gives it a lot of its ergonomics, but it makes multi-tab flows, cross-origin navigation, and some iframe interactions awkward or unsupported. Playwright handles multiple tabs, multiple browser contexts, and cross-origin navigation natively.

If your tests cross domains, open new tabs (OAuth popups, payment redirects), or juggle several user sessions at once, Playwright removes a class of friction here.

Developer experience and debugging

This is where Cypress earns its loyalty. The interactive time-travel runner lets you step back through each command and see the app's state at every point, and automatic waiting makes tests read cleanly without manual sleeps. For local development on a single-page app, many developers still find Cypress the more pleasant tool.

Playwright has closed most of the gap with its Trace Viewer, UI mode, and codegen, and its expect auto-retries similarly to Cypress. The debugging experience is now excellent on both; Cypress's edge here is narrower than it was two years ago.

Cost

Both frameworks are open source and free to run yourself. The costs show up at scale:

Cypress: parallel test orchestration and the dashboard are a paid Cypress Cloud plan.
Playwright: parallelization is free, but you still pay for CI minutes and for maintaining the browser binaries your runners download and update.

Neither cost is the framework license. Both are the operational tax of running real browsers in CI, which is worth keeping in mind for the screenshot section below.

A quick decision table

Requirement	Playwright	Cypress
Chromium, Firefox, WebKit/Safari	Yes, all three	Chromium-family, no WebKit
Free native parallelization	Yes	Paid (Cypress Cloud)
Languages	JS, TS, Python, Java, .NET	JS, TS only
Multiple tabs / cross-origin	Native	Restricted
Interactive time-travel runner	Trace Viewer / UI mode	Yes, its signature feature
Best fit	Cross-browser, CI-heavy, polyglot teams	JS single-page apps, local-first

Where both frameworks agree: screenshots for UI verification

Both Playwright and Cypress can take screenshots, and both do it well for the app under test. cy.screenshot() in Cypress and page.screenshot() in Playwright each capture what the runner controls, and both auto-capture on failure so you get evidence when a test breaks. For an in-suite capture of your own app, use the framework you already picked. For the Cypress specifics see how to take screenshots in Cypress; for Playwright see how to take screenshots in Playwright.

Two capture jobs sit outside what either framework is built for:

Capturing a URL your test suite does not control. A third-party page, a partner's site, or your own production URL. Cypress restricts cross-origin navigation, and pointing a whole Playwright run at an external site just to grab one image is heavy.
Consistent renders across environments. A screenshot's fonts, emoji, and anti-aliasing depend on the OS the browser runs on. A shot from your macOS laptop and one from a Linux CI runner differ, which produces false diffs in visual regression testing. Baselines need one fixed rendering environment.

For both jobs, a hosted screenshot API captures a URL from a fixed environment and returns an image, so you skip provisioning and maintaining a browser for that one task. Here is the same "capture a page" idea 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/pricing",
    "width": 1280,
    "height": 720,
    "full_page": true,
    "format": "webp"
  }'

The response includes a hosted image_url you can archive or diff:

{
  "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 options you know from either framework map across directly. A full-page capture becomes "full_page": true, an element capture becomes a "selector" field, and any wait you would add before a shot 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 from a live URL, after it settles
-d '{
  "url": "https://example.com/dashboard",
  "selector": "[data-testid=chart]",
  "delay_ms": 800,
  "format": "png",
  "width": 1280,
  "height": 720
}'

Grabbit is prepaid at $0.002 per live grab, and credits do not reset or expire monthly, so an occasional external capture in CI does not carry a subscription's worth of overhead. Test-environment keys return free placeholder images, so you can wire it up before adding a card.

The bottom line

Playwright has the momentum, and for cross-browser, CI-heavy, or polyglot projects it is the clearer pick in 2026. Cypress is far from obsolete: for a JavaScript single-page app where local debugging experience matters most, it is still an excellent choice. Pick on your actual requirements, browser targets, parallel scale, languages, and multi-origin needs, not on which framework is trending.

Whichever you choose, when you need to screenshot a URL your suite does not control or produce a consistent baseline from a fixed environment, reach for a screenshot API instead of bending your test runner to do it. For choosing a hosted service honestly, the screenshot API comparison weighs the trade-offs.

Originally published on the Grabbit blog.

HTML to PNG: How to Render HTML to a PNG Image (URL to PNG via API)

Nico Acosta — Tue, 04 Aug 2026 11:41:53 +0000

The reliable way to render HTML to a PNG is to host the HTML at a URL, then capture that URL with a screenshot API and format set to png. The API loads the page in a real headless browser and returns a hosted PNG image. This is the same pattern behind a dynamic OG image or a generated card: your HTML lives at a route, and one API call turns it into a pixel-accurate image.

The reason to lead with the URL is that most "HTML to PNG" jobs are really "render this page and give me a PNG." The top converters agree: PDFCrowd's own answer to "can I convert HTML to image" is to open its web-page tab and enter the URL, and cdkm and Convertio both take a URL as the input. If you have HTML you control, publishing it at a URL first is what makes the capture repeatable from code.

Render an HTML page to PNG with one API call

Host your HTML at a URL (a public page, a template route in your app, or a local server), then POST that URL. PNG is the default format, so a plain capture already returns a PNG:

curl -X POST https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/card",
    "width": 1200,
    "height": 630,
    "format": "png"
  }'

The response is JSON with a hosted image_url:

{
  "id": "grb_01jx...",
  "status": "done",
  "target_url": "https://example.com/card",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....png",
  "width": 1200,
  "height": 630,
  "format": "png",
  "bytes": 41280,
  "execution_ms": 910,
  "created_at": "2026-08-04T09:00:00.000Z"
}

Store that image_url, embed it in a page, or hand it to another service. Because PNG is the default, leaving format off entirely still returns a PNG.

The parameters you will reach for most:

width (320 to 1920) and height (240 to 1080) set the canvas. For a social card, 1200 by 630 matches the standard OG size.
full_page: true captures the entire scrollable document instead of stopping at the viewport height, which is what you want for a long template or a document-style page.
delay_ms (0 to 10000) waits before the capture, useful when your template renders a chart or fetches data after load.
selector crops the capture to a single element, so you can point the API at one card in a larger page.

The honest limit: a URL, not a raw HTML string

A URL-based screenshot API renders a URL. It does not accept a raw HTML string in the POST body. If your HTML only exists as a string in memory, the reliable pattern is to host it at a route first, then capture that route.

In practice this is less work than it sounds, and it is the same approach that powers dynamic OG images:

Add a template route in your app, for example /card, that renders the HTML you want as an image.
Pass the dynamic parts as query parameters, like /card?title=Launch&user=nico.
Point the screenshot API at that URL.

One template route then produces unlimited images, and the HTML stays versioned in your codebase instead of living as a pasted blob in a converter. If your goal is a chart or a card that is already rendered in the browser in front of the user, that is a different job. A client-side library such as html-to-image rasterizes a DOM node directly with canvas, no server involved. It cannot render a URL on a server, so it does not help in a cron job or a CI pipeline, but for exporting what the user is looking at right now it is the right tool. See HTML to Image: How to Render HTML to PNG, JPG, or WebP for that side-by-side.

Why PNG (and when to pick JPG or WebP instead)

PNG earns its place when the output has to be exact. It is lossless, so text stays sharp and edges stay crisp with no compression artifacts, and it supports transparency, which matters when a card or badge needs to sit on a colored background. Those two properties also make PNG the standard baseline format for visual regression testing: a lossless render compares byte-for-byte against the previous run, so a real UI change is not drowned out by JPG compression noise.

The tradeoff is file size. A full-page PNG of a long document can get large. When size matters more than a perfect pixel, JPG produces the smallest file for photographic content and WebP produces the smallest file overall at similar quality. Because the API takes format per request, you can render the same URL as a PNG for your test baselines and a WebP for the version you ship to users, changing one word. For a JPG-specific walkthrough, see How to Convert a Webpage to JPG; for the general URL-to-image path, How to Screenshot a Website from a URL covers the same call without the format focus.

Why an API over a local converter

Running the conversion yourself means installing headless Chromium, keeping it patched, and tearing down a browser session after every render. That is a real maintenance tax for what is ultimately one HTTP call. A hosted screenshot API moves the rendering machinery somewhere else: you send a URL, you get back a hosted PNG, and there is no browser binary in your deploy.

Grabbit prices this at a flat $0.002 per live grab, with prepaid credits that never reset or expire monthly, so a $50 annual plan is 25,000 renders you can spend whenever you need them. Test-environment keys return free placeholder images, so you can wire the whole flow up before adding a card. See the screenshot API for the full parameter reference.

Originally published on the Grabbit blog.

How to Convert a Webpage to JPG (URL to JPG Image via API)

Nico Acosta — Mon, 03 Aug 2026 11:45:35 +0000

To convert a webpage to a JPG, send the page URL to a screenshot API with the format set to jpeg, and it returns a hosted JPG image. One HTTP request in, one image URL out. The headless browser that renders the page runs in the cloud, so there is no converter to install and no local Chrome to babysit.

That is the fast path. Below is the whole request, an important distinction the search results blur, when JPG is actually the right format, and how to get full-page and dimension options right.

The quick answer

If you just want a URL turned into a JPG from your code, this is the whole thing:

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": "jpeg"
  }'

The response is JSON with a hosted image_url:

{
  "id": "grb_01jx...",
  "status": "done",
  "target_url": "https://example.com",
  "image_url": "https://cdn.grabbit.live/grabs/grb_01jx....jpeg",
  "width": 1280,
  "height": 720,
  "format": "jpeg",
  "bytes": 61240,
  "execution_ms": 910,
  "created_at": "2026-08-03T09:00:00.000Z"
}

Store that image_url, embed it, or hand it to another service. Note the format value is jpeg, not jpg. They mean the same file, but the API takes the spelled-out jpeg.

First, the distinction that matters

Search for "webpage to jpg" and the results split into two jobs that sound alike but are opposites. Getting the wrong one wastes your time.

File conversion (not this). Most of the top results, like iLoveIMG, CloudConvert, Adobe Express, and Canva, are WebP-to-JPG converters. You upload an image file you already have, and they change its format. The input is a picture. If you already own a .webp and want a .jpg, that is your tool, and you do not need an API for it.

URL to image (this). You have a web address, not a file, and you want a picture of the live page as it renders. FreeConvert's "Web Page to JPG Converter" and the "convert HTML webpage to JPG" how-tos are this job. The input is a URL. The page has to be loaded in a browser, laid out, and captured, and that is what a screenshot API does.

This guide is about the second job: URL in, JPG out. If you have an image file and just need a format change, use one of the file converters above and move on.

Converting a webpage URL to JPG with an API

For anything repeatable, a screenshot API is the shortest path. You already saw the curl call. Here is the same request in a couple of languages, since "how do I do this in my stack" is the real question.

Python, using requests:

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": "jpeg",
    },
)
data = resp.json()
print(data["image_url"])

Node.js, using the built-in fetch:

const resp = 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,
    height: 720,
    format: 'jpeg',
  }),
});
const data = await resp.json();
console.log(data.image_url);

Every one of these is a plain HTTP call. No chromedriver, no 300 MB Chromium download, no async browser session to tear down afterward. That is the whole reason to reach for an API over a local converter: the rendering machinery lives somewhere else. The screenshot from URL guide walks through the same call in more detail if you are wiring it up for the first time.

When JPG is the right format (and when it is not)

The format field takes png, jpeg, or webp, and picking jpeg is a deliberate choice. JPG earns its place in two situations:

File size is the priority. JPG produces the smallest file of the three formats, which matters when you are storing thousands of captures or when a full-page shot of a long page would otherwise be several megabytes. The tradeoff is lossy compression, so fine text can soften slightly at low quality.
You need universal support. Every browser, CMS, email client, and image pipeline handles JPG without a second thought. It is the safe default when you do not control where the image ends up.

Reach for a different format when:

You need lossless output or transparency. Use PNG. For a visual regression baseline the image has to be byte-stable so a real UI change is the only thing that produces a diff, and JPG's compression can shift a few pixels between renders. The website to PNG guide covers that case.
You want small files without the JPG artifacts. Use WebP. It compresses better than JPG at similar visual quality, which is why it is a good default for large libraries of screenshots. The webpage to image guide compares all three formats side by side.

Switching is a one-word change in the request body, so you can render the same page as jpeg, png, and webp and compare the file sizes on your own pages before committing.

Capturing the full page, not just the viewport

By default a capture stops at the viewport height you request. To convert the entire scrollable page into one tall JPG, set full_page to true:

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": "jpeg"
  }'

With full_page on, height is ignored and the render extends to the bottom of the document. This is where JPG pulls ahead: a full-page capture of a long landing page or article can be very tall, and JPG keeps that file small where PNG would balloon. The full-page screenshot guide covers the edge cases like lazy loading and sticky headers.

width must be between 320 and 1920 pixels, and height between 240 and 1080. If the page renders content client-side after load, add "delay_ms": 1500 to wait before the capture fires, or "selector": "#main" to wait for a specific element to appear.

When a local converter is the better call

An API is not always the answer. Render locally instead when:

You already have a full HTML string, not a URL. If the markup lives in your app and never gets served at an address, a local page.screenshot() in Puppeteer avoids a round trip. See HTML to image for that pattern, including the trick of hosting your template at a URL and then capturing it.
You are doing a single manual capture. In Chrome or Edge, open the command menu with Ctrl+Shift+P (Cmd+Shift+P on Mac), type "screenshot," and choose "Capture full size screenshot," then save the result.
You cannot make outbound requests. In an air-gapped environment an API is off the table, so a bundled headless browser is the only option.

For everything else, especially anything that runs on a schedule or in CI, the API path keeps your deployment small and removes an entire class of "it works locally but not in the container" failures.

Next steps

The automated screenshots guide covers scheduling, async jobs, and webhooks for turning many URLs into JPGs in a pipeline. For the full format comparison, see webpage to image, and for the lossless alternative, website to PNG.

Originally published on the Grabbit blog.

How Percy Visual Testing Works (and When a Screenshot API Fits Your Workflow)

Nico Acosta — Thu, 30 Jul 2026 11:43:43 +0000

Percy is a hosted visual testing platform, now part of BrowserStack, that catches UI changes you did not mean to ship. You add a snapshot call to your existing tests, Percy renders each snapshot in its own browser fleet, diffs it against a stored baseline, and shows the visual differences in a review dashboard where someone approves or rejects the change. This guide walks through how that pipeline works, where it shines, and the narrower job where a screenshot API is the simpler fit.

How Percy visual testing works

Percy is visual regression testing with the hard parts managed for you: baseline storage, consistent rendering, and a review UI. The pipeline has four stages.

1. Snapshot. In your test, you call Percy's snapshot function at the moment you want to capture the page. With the Playwright or Cypress SDK it looks like one extra line:

import { test } from '@playwright/test';
import percySnapshot from '@percy/playwright';

test('homepage renders correctly', async ({ page }) => {
  await page.goto('https://example.com');
  await percySnapshot(page, 'Homepage');
});

The snapshot call does not diff anything locally. It serializes the page's DOM and assets and uploads them to Percy.

2. Render. Percy takes that serialized DOM and renders it in its own browser fleet, across the browser and viewport-width combinations you configure. Rendering server-side is the point: it removes the "passes on my Mac, fails in CI" problem that plagues locally captured baselines, because every snapshot is rendered in the same controlled environment.

3. Diff against the baseline. Percy compares each freshly rendered snapshot against the stored baseline for that page (the last approved version). It highlights the changed pixels. The first time a snapshot runs there is no baseline, so that render becomes the baseline.

4. Review and approve. Changed snapshots land in a Percy dashboard. A reviewer looks at the highlighted diff and either approves it (an intentional change, which becomes the new baseline) or rejects it (a regression to fix). Approval can gate the pull request, so a visual change cannot merge until a human has signed off.

The value is the loop: your existing tests feed snapshots in, and Percy handles rendering, baselines, and the human review step so you are not eyeballing every page after every commit.

What Percy is good at

Reviewing intended vs. unintended change. The dashboard and approve/reject flow are the real product. Percy is built around a human confirming that a visual change was on purpose.
Cross-browser and responsive diffs. Because it renders server-side, one snapshot can be checked across several browsers and viewport widths without you running each locally.
Component and page coverage inside a test suite. If you already have Playwright, Cypress, or Storybook tests, adding snapshots is incremental.

Where the cost adds up

Percy prices per snapshot, per browser, per commit. That number grows fast: pages times viewport widths times browsers times how often your suite runs. A free tier covers small projects, but a busy team testing many pages across several browsers on every push can move through an allotment quickly. That is the tradeoff for a managed review UI, and it is worth it when reviewing visual change is the job. It is overkill when all you need is to capture and store an image.

Where a screenshot API fits instead

Percy diffs and reviews. A screenshot API captures. Those are different jobs, and plenty of "visual" tasks are pure capture with no diff or review step:

Capturing pages outside your test suite. A live production page, a marketing page, or a third-party page you do not control is a capture job, not a test assertion. There is no baseline to approve.
A stable baseline or reference image. If you want a consistent render of your deployed page to compare against, capturing it through a hosted browser gives you one image that does not depend on any developer's machine.
Scheduled snapshots for records or monitoring. Grabbing the same set of URLs on a schedule to archive or watch them is capture, not per-commit regression testing.

For those, you do not need a snapshot SDK wired into a test runner or a per-browser review dashboard. You need one request that returns a hosted image:

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 gives you a hosted image URL you can store as a reference or feed into your own diffing:

{
  "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 and height 240 to 1080, full_page captures the whole scroll height, format is png, jpeg, or webp, and delay_ms (0 to 10000) lets late-loading content settle before the shot. To be clear about scope: Grabbit captures the images. The diffing, the approve/reject review, and the pass/fail belong in Percy or your VRT tool. Pricing is flat at $0.002 per capture with credits that do not reset monthly, so a scheduled capture job has a predictable cost rather than a per-snapshot meter.

Percy or a screenshot API: which to reach for

Reach for Percy when the job is reviewing visual change: you want a managed baseline, cross-browser diffs, and a human approving each change before it merges, driven from your existing tests.
Reach for a screenshot API when the job is capture: pages outside your suite, a stable reference image, or scheduled snapshots, where there is no baseline to approve and you just need the image.

Many teams use both. Percy guards the components and pages inside the test suite; a screenshot API captures everything that lives outside it.

For the fuller picture, see the practical guide to visual regression testing and the roundup of visual regression testing tools. If your stack is Playwright, Playwright visual regression testing shows the built-in, no-service version of the same loop.

Originally published on the Grabbit blog.

How to Build Rich Link Previews Like Slack and iMessage

Nico Acosta — Wed, 29 Jul 2026 11:40:38 +0000

When you paste a link into Slack, iMessage, or Discord, it usually expands into a card with a title, a short description, and an image. That card is a rich link preview, and when yours shows up as a bare URL instead, the cause is almost always the same across every platform: the page is missing the Open Graph tags those apps read, or its og:image points at something they cannot fetch. This guide covers how the previews work, the exact tags to add, and how to give the card a real image of your page instead of a generic logo.

How a rich link preview works

Slack, iMessage, Discord, and the social platforms do not screenshot your page on demand or guess at its content. When a URL is posted, the app fetches your page's raw HTML and looks for Open Graph meta tags in the <head>. Four tags drive the entire card:

<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A one-line summary of the page." />
<meta property="og:image" content="https://yourdomain.com/og.png" />
<meta property="og:url" content="https://yourdomain.com/page" />

og:title and og:description become the text. og:image becomes the picture. og:url is the canonical link the card points at. If a page has no Open Graph tags at all, the app falls back to the bare URL with no card. That is what a "broken" preview almost always is: missing or unreachable tags, not a bug in Slack or iMessage.

Two details trip people up on every platform:

The fetcher reads the raw HTML, not the rendered page. It does not run your JavaScript. If your meta tags are injected client-side (a single-page app that sets them after load), the fetcher never sees them. The tags must be in the HTML the server sends.
og:image must be an absolute, public URL. A relative path like /og.png will not resolve. Use the full https://yourdomain.com/og.png, and make sure that URL is reachable without a login or a redirect the app cannot follow.

The tags every platform reads

The good news for anyone building link previews into an app: you do not write a different set of tags per platform. Open Graph is the shared standard, so one correct set of tags produces a rich card in Slack, iMessage, Discord, Facebook, and LinkedIn at once. Add one X-specific tag and you cover X (Twitter) too:

<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A one-line summary of the page." />
<meta property="og:image" content="https://yourdomain.com/og.png" />
<meta property="og:url" content="https://yourdomain.com/page" />
<meta name="twitter:card" content="summary_large_image" />

twitter:card set to summary_large_image tells X to render the wide card instead of a small thumbnail; X falls back to your og:image for the picture, so you do not need a separate twitter:image. That is the whole tag set. The work that remains is producing the image, and making sure the tags actually reach the fetcher.

Making the preview image a real render of your page

The og:title and og:description are just strings. The og:image is the part that makes a preview feel rich, and it is also the part most people get wrong by shipping a single generic logo for every URL. For a marketing page, a docs page, or a product page, the best preview image is often a clean shot of the page itself.

You can produce that with a screenshot API: point it at the URL, get back a hosted image, and use that image as your og:image.

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yourdomain.com/og",
    "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 the 1200 by 630 card is comfortably in range. delay_ms (0 to 10000) gives client-rendered content or web fonts a moment to settle before the capture fires. Drop the returned image_url into your tag:

<meta property="og:image" content="https://cdn.grabbit.live/grabs/grb_01jx....png" />

Capture once per unique page and cache the image_url alongside the page record rather than rendering on every request. A common pattern is to build a dedicated /og route with your normal components, capture that at 1200 by 630, and reuse the result everywhere. The same template-and-cache approach is covered in how to generate dynamic OG images from any URL, and the per-platform fix-it details are in how to make your Discord links unfurl.

Why 1200 by 630 covers every platform

Slack, iMessage, Discord, Facebook, X, and LinkedIn all render the same 1.91 to 1 aspect ratio as a large card, and 1200 by 630 pixels is the size that satisfies all of them. That is why one og:image fixes the preview everywhere at once: you are not producing a Slack image and an iMessage image and a Discord image, you are producing one Open Graph image that every reader parses.

Smaller images still work, but many apps fall back to a small thumbnail beside the text below roughly 300 pixels wide, which reads as a weaker preview. Stay at 1200 by 630 and the card is full-width on every platform.

Why your preview still is not showing

If the tags are present and the image URL works in a browser but a platform still shows nothing, work through these in order:

The platform cached the old version. Slack, iMessage, Discord, and Facebook all cache the metadata they fetched the first time a URL was posted, so editing your tags will not update a preview that already rendered. Append a unique query string, such as ?nocache=1, and post the link again so the app treats it as a new URL and re-fetches. Facebook and X also offer manual re-scrape tools in their sharing debuggers.
The image is behind auth or a redirect. If og:image requires a login, sits behind a paywall, or redirects in a way the fetcher will not follow, the card renders without an image. Test the raw image URL in a private browser window.
The tags are set by JavaScript. The fetchers read static HTML and do not execute scripts. Server-render the meta tags so they are in the initial response.
The image is too small. Below roughly 300 pixels wide, many apps render a small thumbnail instead of a full card. Use 1200 by 630.

Re-fetch first, because a stale cache is the single most common reason a correct tag set still shows nothing.

The short version

A rich link preview is your page's Open Graph tags rendered as a card, and every platform reads the same four tags. Add og:title, og:description, og:image, and og:url server-side, plus twitter:card for X; make og:image an absolute, public, 1200 by 630 URL; and append ?nocache=1 to force a refresh after changes. If you want the image to be a real render of the page instead of a static logo, a screenshot API turns the live URL into the hosted image you point og:image at. New to the format? Start with what is an OG image.

Originally published on the Grabbit blog.

How to Screenshot Every Page of a Website (Build a Visual Site Audit)

Nico Acosta — Tue, 28 Jul 2026 11:39:49 +0000

You are redesigning a site, migrating a CMS, or auditing a competitor, and you need a screenshot of every page, not just the one you happen to have open. The head query for this reads two ways. One is manual: capture the single long page in front of you. The other is the job most developers actually mean here: turn a whole site into one image per page for a visual inventory. This guide is about the second one.

The short answer

To screenshot every page of a website, do two things in order:

Enumerate the routes. Get a flat list of the site's URLs, usually from its sitemap.xml or a small crawl step you run.
Loop the list through a capture. Send each URL to a screenshot API one at a time and collect the hosted image for every page.

There is no magic "shoot the whole site in one call" primitive. Every tool does the same thing underneath: it visits each page in turn and renders it. The real work is building the route list and driving the loop.

Why the manual tools stop at one page

The top of this SERP is full of single-page capture tools: the Chrome command menu's "Capture full size screenshot," Edge's Web capture, and extensions like GoFullPage. They are excellent at one thing, capturing the entire scrollable length of the page you are currently on. None of them screenshot a site. You would have to open every page yourself and press the capture key on each, which is exactly the tedium you are trying to avoid on a fifty-page audit.

For a true whole-site job you need the route list and a loop, which means code.

Step 1: enumerate the site's routes

Before you can capture every page, you need to know every page. Two reliable sources:

The sitemap. Most sites publish https://example.com/sitemap.xml, an XML file listing their canonical URLs. Fetch it, parse the <loc> entries, and you have your list. This is the cleanest source because the site owner already curated it.
A crawl step. No sitemap? Run a small crawler that starts at the homepage, follows internal links, and collects unique routes. Keep it scoped to the site's own domain so you do not wander off.

Either way you end up with a plain array of URLs. That array is the only input the capture loop needs.

One honest note up front: a screenshot API captures the URLs you hand it. It does not crawl your site or follow links on its own. The enumeration in this step is a job you run; the API's job starts once you have the list.

Step 2: loop the routes through a screenshot API

With the list in hand, each capture is a single HTTP request. 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 routes, capture each one full-page, and collect the results.

// routes.json is your enumerated list, e.g. parsed from sitemap.xml
import { readFileSync } from 'node:fs';

const routes = JSON.parse(readFileSync('routes.json', 'utf8'));
const audit = [];

for (const url of routes) {
  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();
  audit.push({ url, image_url: data.image_url });
}

console.table(audit);

Each response includes a hosted image_url, so you can drop the results straight into a CSV, a database, or a static gallery page. Because every request is independent, one page that 404s or hangs never sinks the rest of the audit. This is the same 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. For the mechanics of driving a flat list of URLs, see how to screenshot a list of URLs; a whole-site audit is that same loop, fed by the routes you enumerated in step 1.

The options that matter for a whole-site audit

Each call in the loop is configured on its own, so a mixed set of pages is no problem:

full_page: true captures the entire scrollable page, not just the viewport. Essential for an audit where you want the whole page on record.
width sets the viewport (320 to 1920). Use one consistent width across the whole site so the pages line up when you compare them side by side.
format can be png, jpeg, or webp. WebP keeps a large audit small on disk; PNG is worth it when you want lossless baselines.
delay_ms waits up to 10 seconds before the capture, which helps on pages that fade content in after load.
selector captures just one element by CSS selector, useful if your audit only cares about, say, the header or a pricing table on every page.

For a large site where you do not want to hold a 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 several-hundred-page run from blocking your script.

Turn the captures into an audit

The reason to screenshot every page is rarely the images themselves, it is what you do with them:

Redesign inventory. Before a rebuild, capture the current site so you have a visual record of every page you are replacing. Nothing gets forgotten in the migration.
Visual QA after a deploy. Re-run the same route list on staging and production and eyeball the pages that changed.
Competitor teardown. Snapshot a competitor's key pages, then re-run the list next month. Save each image_url next to its source URL and a timestamp and the diff over time tells a story, which is the foundation of website change monitoring.

Because the loop is deterministic and hands-off, you can run it on a schedule with cron or a CI job and have a fresh visual snapshot of the whole site whenever you need one.

Wrapping up

Screenshotting every page of a website is always two steps: enumerate the routes, then loop them through a capture. Consumer extensions cover the single page in front of you; a whole-site audit needs the route list (from a sitemap or a crawl you run) and a loop that turns each URL into a hosted image. Point the loop at your list, collect the image URLs, and you have a repeatable visual audit that runs anywhere, including CI and serverless. To automate it end to end, see Grabbit's automated screenshots.

Originally published on the Grabbit blog.