Website screenshot API: capture any page with one request

A website screenshot API turns a URL into an image through a single HTTP request. You send the address of a page, the API renders it in a real browser, and you get back a PNG, JPEG or PDF. No headless Chrome to install, no Docker image to maintain, no memory leaks at 2am.

This guide covers the requests you will actually send: a basic capture, a full page screenshot, device emulation, waiting for a single page app to finish rendering, capturing one element, and cleaning ads and cookie banners out of the shot. Every example is a real request against the ScreenshotBee API, but the concepts carry across any website screenshot API you pick.

If the page you need to capture does not exist on the web yet, because you are rendering your own template, read how to convert HTML to an image instead.

Your first screenshot

Create an account, copy your API key from the dashboard and send one request. The only required field is a source: either a url or raw html.

curl -X POST "https://screenshotbee.com/api/capture-screenshot" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "url": "https://example.com",
    "format": "png"
  }'

The response carries the URL of the finished image along with the metadata you need for logging and debugging.

{
  "success": true,
  "result": {
    "screenshotUrl": "https://cdn.screenshotbee.com/...png",
    "statusCode": 200,
    "taskDurationSec": 2.4,
    "pageResourceSizeInKB": 1840,
    "success": true
  }
}

Full page screenshots

A viewport screenshot captures what fits on one screen. A full page screenshot scrolls the whole document, triggers lazy loaded images along the way and stitches the result into one tall image. This is the single most requested option in any website screenshot API, and the one most likely to expose bugs in a self built setup.

Set fullsize_screenshot and let the renderer handle the scrolling.

{
  "url": "https://example.com",
  "format": "png",
  "fullsize_screenshot": true,
  "viewport_width": 1440,
  "viewport_height": 900
}

• Lazy loaded images below the fold render before the capture, instead of arriving as grey boxes
• Sticky headers are handled, so you do not get the same navigation bar repeated down the image
• Very long pages still come back as one file rather than a set of tiles you have to join yourself

Device emulation

Capturing how a page looks on a phone is not the same as making the browser window narrow. Real device emulation sets the user agent, the device pixel ratio and touch support, so responsive breakpoints and retina assets behave the way they do on the device itself.

Pass a device name from the known device list, or set an exact viewport and scale factor yourself.

{
  "url": "https://example.com",
  "pre_defined_device": true,
  "device_name": "iPhone 15 Pro"
}

// or an exact viewport
{
  "url": "https://example.com",
  "viewport_width": 1440,
  "viewport_height": 900,
  "device_scale_factor": 2
}

Waiting for single page apps

The most common cause of a blank or half rendered screenshot is capturing before the page has finished. React, Vue and Svelte apps often return an empty shell in the initial HTML and fill it in afterwards, so a naive capture catches the shell.

There are two ways to wait. A fixed delay is blunt but reliable. Waiting for a selector is precise: the capture fires the moment the element you name exists in the DOM.

{
  "url": "https://app.example.com/dashboard",
  "has_screenshot_wait_time": true,
  "screenshot_wait_time": 3000
}

• Prefer waiting for a selector when you control the page and know what element proves it is ready
• Use a fixed delay for third party pages where you cannot predict the markup
• Do not set a delay larger than you need: every second of waiting is a second of render time

Capturing a single element

Sometimes you want one card, one chart or one pricing table, not the whole page. Give the API a CSS selector and it crops to that element, at its natural size, with everything else discarded.

{
  "url": "https://example.com/pricing",
  "is_selector": true,
  "selector": "#pricing-card"
}

Cleaning up the shot

Real web pages fight screenshots. Cookie banners cover the hero, ad slots load late and shift the layout, and chat widgets park themselves in the corner. A website screenshot API worth using handles these for you rather than leaving you to write selectors for every site on the internet.

{
  "url": "https://news.example.com",
  "fullsize_screenshot": true,
  "block_ads": true,
  "hide_cookie_banner": true,
  "block_cookies": true
}

Capturing on a schedule

For monitoring, archiving and compliance you want the same page captured over and over without running a scheduler yourself. Schedules built into the dashboard capture any page every hour, every six hours, every twelve hours or once a day, and every run lands in your activity history with a timestamp.

This is what most teams reach for when they need website archiving, competitor monitoring or a visual record of what a page said on a given date.

What a screenshot costs

Pricing in this market splits into two models. Subscriptions sell you a monthly quota and delete whatever you do not use. Pay as you go sells credits that stay in your account until you spend them.

ScreenshotBee is the second kind. One credit is one successful screenshot, credits start at $9 per 1,000 and fall to $3.50 per 1,000 at volume, and failed captures are never charged. Every new account starts with 100 free credits and no card, which is enough to work through every example above.

The full ladder is on the pricing page, and screenshot API pricing compared works through what a monthly quota actually costs you.

Failure modes worth knowing about

Most screenshot problems are one of a small set. If a capture comes back wrong, start here:

• Blank or partial image: the page had not finished rendering. Add a wait condition
• Missing images halfway down a full page capture: lazy loading was not triggered. Use full page mode rather than a tall viewport
• A cookie banner covering the hero: enable cookie banner hiding
• Fonts rendering as fallbacks: the web font arrived after the capture. A short wait fixes it
• A login wall instead of the page: pass cookies or an authorization header with the request
• Layout different from your browser: check the viewport width. Many sites change layout well below 1440px