The same screenshot, both ways

html2canvas (in the browser)

import html2canvas from "html2canvas";

const canvas = await html2canvas(document.body);
const dataUrl = canvas.toDataURL("image/png");

// Caveats that are inherent rather than bugs:
//   - only CSS html2canvas implements is drawn
//   - cross-origin images need a proxy or taint the canvas
//   - iframes, some filters, and some transforms do not render
//   - it only sees the page the user is already on

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 html2canvas if…

• You are capturing the user's own current view, including state that exists only in their browser — an unsaved form, a client-rendered chart, a signed-in dashboard.
• You want no server round-trip and no API key at all.
• Approximate fidelity is fine, and your markup is simple enough to stay inside what it implements.
• You need it to work offline.

Use a hosted API if…

• The output has to look like the page actually looks. A real browser renders what the browser renders, including the CSS html2canvas has not implemented.
• You need to capture a URL rather than the page the script is on.
• Cross-origin images, iframes or web fonts appear in the output.
• You need PDF output, or a capture taken from your backend where there is no DOM at all.

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

• Generating images from an HTML template — server-side rendering instead of canvas in the browser