The same screenshot, both ways

Selenium (self-hosted, Python)

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

opts = Options()
opts.add_argument("--headless=new")
opts.add_argument("--window-size=1280,720")

driver = webdriver.Chrome(options=opts)
driver.get("https://example.com")
driver.save_screenshot("out.png")
driver.quit()

# save_screenshot captures the viewport. Full-page means either
# scrolling and stitching yourself, or resizing the window to the
# document height and hoping nothing is position: fixed.

getSnap.dev

curl -X POST https://api.getsnap.dev/v1/screenshot \
  -H "X-API-Key: sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "format": "png", "full_page": true}'

# -> {"url": "https://cdn.../screenshots/....png"}

What running it yourself costs

These are not estimates. They are measured from the getSnap.dev production deployment on 5 October 2026, which runs Playwright 1.50 on Chromium:

What	Measured	Why it matters
Container image	3.97 GB	Pulled on every deploy, cached on every CI runner, stored in every registry.
Chromium on disk	656 MB	Downloaded by playwright install; a cold CI cache pays for it every time.
Memory ceiling	3 GiB	A full-page capture of a heavy site is the spike that finds this limit.
Concurrent captures	3	Throughput against OOM risk. Raising it is not free.
Capture timeout	30 s	Long enough for slow pages, short enough that a stuck one does not hold a worker.

None of this is exotic. It is simply the part that does not appear in the five-line example on the library's front page.

What actually breaks when you run it yourself

Not a list of hypotheticals. Every one of these is fixed in getSnap.dev's source with a comment explaining the symptom, because each one reached production first.

Teardown that skips itself and leaks a renderer

The obvious cleanup is wrong:

} finally {
  await page.close();
  await context.close();   // never runs if the line above rejects
}

When the renderer has already died — "Target closed", an OOM on a heavy full-page capture, the common cases — page.close() rejects and the context is never closed. The orphaned context keeps its renderer process alive on the shared browser until the container hits its memory ceiling. Worse, the rejection propagates out of the finally and replaces the real capture error, so your logs name the wrong cause.

networkidle that never arrives

Waiting for the network to go quiet is the natural choice and it is a trap. Any page with long-polling, websockets or analytics beacons never goes quiet, so the capture runs to the full timeout and fails. You need a weaker condition available per request, and you need to decide which pages get which.

Options that contradict each other

Set quality on a PNG and Chromium throws options.quality is unsupported for the png screenshots. Pass a cookie with both a URL and a domain and you get Cookie should have either url or path. These are easy to fix once and easy to reintroduce, and they surface as a failed capture rather than a validation error.

Capacity you have to pick in advance

This deployment runs 3 concurrent workers against a 3 GiB ceiling with a 30-second capture timeout. Those numbers are a compromise between throughput and being OOM-killed, and they are yours to tune, re-tune, and get paged about.

Which should you use?

Stay with Selenium if…

• You already run a Selenium Grid and the marginal cost of one more job is near zero.
• You need browsers other than Chromium — real Safari, real Firefox, old versions, real devices.
• Your organisation standardised on WebDriver and that is not a decision you are making.
• You are testing, and the screenshot is evidence attached to a failure rather than a product feature.

Use a hosted API if…

• You want a full-page capture without writing a scroll-and-stitch routine.
• You want one HTTP call instead of a driver, a browser binary and a matching driver version.
• You do not want to maintain a Grid, or pay for one idling.
• You need PDFs, videos or OG images too, which WebDriver does not meaningfully cover.

Frequently asked questions

Next steps

• Playground — take a capture in the browser, no signup
• Code examples — every option, with cURL, Node.js and Python
• Quick starts for Python, Node.js, PHP, Ruby, Go, Java, C#
• Already paying for a screenshot API? Compare the hosted options

Related reading

• Puppeteer vs Playwright in 2026 — the two libraries most teams move to from Selenium