How to Screenshot a Webpage Programmatically (URL to Image at Scale)

To screenshot a webpage programmatically, send one HTTP POST to a screenshot API with the target URL, then read the hosted image URL from the response. The headless browser runs in the cloud, so there is nothing to install and the same call works from a script, a serverless function, or a CI pipeline.

That is the whole job for a single page. The reason people search for this is that capturing one page is trivial and capturing many reliably is not. Below is the single-call version first, then how to run it over a full URL list without the capture step eating your afternoon.

The one-call version

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

The response is JSON with a hosted image_url you can store and serve directly:

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

The parameters you will reach for most:

• width between 320 and 1920 pixels, height between 240 and 1080 (defaults 1280 x 720).
• full_page: true captures the entire scrollable page instead of the viewport. When it is on, height is measured from the rendered page, so you do not set one.
• format is png, jpeg, or webp. WebP is the smallest at comparable quality, which matters once you are storing thousands of captures.
• delay_ms (0 to 10000) waits a fixed time after load, and selector waits for a specific element. Use these for pages that render content client-side.

Why "just screenshot these URLs" is harder than it sounds

The single call is easy. The trouble starts the moment the job is "screenshot these 300 pages," because real pages fight the camera. Lazy-loaded images have not appeared yet. A cookie or consent banner sits on top of the content. Infinite-scroll pages never signal that they are done. Half the captures come back garbage, and the fix is not writing a loop, it is getting the wait-and-scroll timing right for pages you do not control.

Running your own headless Chrome gives you full control over that timing, but you also own the Chromium binary, the fonts and locale on the render host, the memory each page uses, and every flaky page that stalls. A hosted API moves that work off your machine: it runs a real browser, executes the page's JavaScript, dismisses common consent banners, and measures full-page height for you. Your code goes back to being a loop over a list.

If you only ever capture one page, that trade does not matter. At scale it is the entire point.

Screenshotting a URL list at scale

For a batch, send one request per URL and add the Prefer: respond-async header so each call returns immediately with a job ID instead of blocking until the render finishes:

import requests

BASE = "https://api.grabbit.live/v1/grabs"
HEADERS = {
    "Authorization": "Bearer sk_live_...",
    "Prefer": "respond-async",
}

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

jobs = []
for url in urls:
    resp = requests.post(
        BASE,
        headers=HEADERS,
        json={"url": url, "full_page": True, "format": "webp"},
    )
    job = resp.json()
    jobs.append(job["id"])
    print(job["id"], job["status"])  # "pending"

# Later, poll each job until it is done, then read image_url:
for job_id in jobs:
    result = requests.get(f"{BASE}/{job_id}", headers=HEADERS).json()
    print(result["status"], result.get("image_url"))

Prefer: respond-async returns 202 with status: "pending". Poll GET /api/v1/grabs/{id} until status is "done", then read image_url. You can queue up to 10 concurrent jobs per team, so throttle your loop to keep that many in flight and top up as needed.

Two honesty notes worth stating plainly. First, the API captures one URL per request. It does not crawl a site and follow internal links for you, so you build the URL list (from a sitemap, a database, or a route manifest) and loop it. Second, live captures cost one credit each at $0.002 per grab on prepaid credits that never reset month to month, so a run of 300 pages is a known, one-time cost rather than a recurring quota you forfeit when idle.

Waiting for JavaScript-rendered content

If a page loads content after the initial HTML, an instant capture can fire before that content is visible. Two options, in order of preference:

• "selector": "#main-content" waits until that element exists in the DOM. Tied to a real content signal.
• "delay_ms": 1500 waits a fixed time. Simple, but it is guesswork, and it slows every capture in the batch.

Prefer selector when the page has a reliable element to key off, and fall back to delay_ms only when it does not. Pure server-rendered pages need neither.

This is also why client-side libraries like html2canvas are the wrong tool here: they serialize the current DOM inside a user's browser and never execute the page's own scripts, so anything loaded after render is missing. A hosted render runs the real page.

Next steps

The automated screenshots guide covers the async job queue, webhooks, and scheduling for production capture pipelines. For the single-page version and the DIY-versus-API tradeoff, see how to screenshot a website from a URL; for the batch pattern in depth, how to screenshot a list of URLs; and for choosing an output format, how to convert a webpage to an image.