What Does a Screenshot API Actually Cost? Price per 1,000 Captures, Self-Hosted vs Managed

The question people actually ask is "how much does a screenshot API cost?" The question they should ask is "what is the total cost of getting N screenshots a month, reliably, for the next two years?" Those two questions have very different answers, and the gap between them is where most of the bad decisions live.

This is the arithmetic on both sides. The managed numbers are exact, because they're published and I can simply read them off the page. The self-hosted side gets shapes and ranges instead of figures, on purpose: your instance size, your region, your average page weight and your provider's rate card move that total by more than any estimate written by someone who has seen none of them. So what follows on that side is a list of which lines exist, which ones scale with capture volume, which ones you pay while completely idle, and how they rank against each other. Fill it in with the rates on your own invoices and you'll have something you can defend in front of a finance team.

The managed side, exactly

Four tiers, monthly, in EUR:

• Free — €0 for 50 requests a month.
• Pro — €7 for 1,000 requests a month.
• Ultra — €20 for 15,000 requests a month.
• Mega AI — €39 for 30,000 requests a month.

The marginal figure that matters is the fully-used rate. Ultra at 15,000 requests works out to €1.33 per 1,000 captures. Mega AI at 30,000 works out to €1.30 per 1,000. Pro is €7 per 1,000 — a small-volume price, and priced as one. Ultra for a full year is €240.

Two things about those numbers before we compare anything. First, they're per request, not per successful screenshot, which matters more than it sounds and gets its own section below. Second, the effective rate you personally pay is the plan price divided by what you actually use, not by what's included — a habit worth keeping, because it's the number that makes plan choices obvious.

What the managed rate covers is not just compute. It covers the browser fleet, the Chromium upgrades, the rendering environment's fonts, storage of the resulting image (the API response carries a hosted link to it), and someone else's pager. That bundling is the entire thing being priced, and it's why comparing a managed rate against a compute-only estimate is comparing two different products.

The self-hosted side, completely

The incomplete version of this list is precisely why people underestimate self-hosting. Here is the complete one.

Compute and memory. This is the line everybody starts with and the one that misleads most, because the mental model is wrong. A Node or Python web process serving JSON has a working set measured in tens of megabytes, and a modest box will handle hundreds of concurrent requests. A Chromium instance rendering a real page — with images, fonts, web workers and a JavaScript heap — has a working set measured in hundreds of megabytes to gigabytes, and the same box will handle a handful of concurrent captures before it starts swapping or getting OOM-killed. Whatever machine size your instinct suggests, the browser needs roughly an order of magnitude more memory per unit of concurrency than you're used to. That changes both the machine you provision and how many of them you need to absorb a burst.

Bandwidth, in both directions. People budget egress and forget ingress. To render a page, the browser downloads the whole page: hero images, video posters, web fonts, third-party scripts, analytics beacons. A single content-heavy page can pull several megabytes in, and you pay for that traffic on a metered path. Exactly which meter depends on your topology — plain egress, inter-zone transfer, or a managed gateway that charges for every gigabyte it forwards — so the useful exercise is working out which of those a capture worker actually trips in your architecture, remembering that a browser is a far heavier network client than the service it replaces. Then you pay again on the way out, serving the resulting images to whoever consumes them.

Object storage, and its growth. Storage is not a monthly cost, it's an accumulating one. At flat capture volume with no retention policy, your storage bill grows every single month, forever, because last month's screenshots are still there. Work it out as captures per month × average image size × months retained, and then look at the twenty-fourth month rather than the first. A lifecycle rule that expires or tiers old captures is a five-minute config change that changes the slope of a line on your bill; almost nobody writes it on day one.

Chromium version churn. This is the line with no end date, which is what makes it a budget item rather than a setup task. Browsers ship every few weeks; each release is another chance that the combination you tested against stops matching itself. Plan against roughly an engineer-week a year, arriving in pieces you didn't schedule. The mechanics of what actually breaks are worked through in the Lambda article linked below.

On-call and incident time. The line with no invoice attached, which is exactly why it disappears from spreadsheets. Browser processes leak, disks fill with crash dumps, and a queue jammed behind one page that never finishes loading does not wait for business hours. Somebody carries that pager.

Add those up and the conclusion is uncomfortable but consistent: at the volumes most teams actually run, the biggest number in the self-hosted column is people's time, not machine time. That engineer-week from the churn line is, by itself, a bigger number than the entire managed bill at every volume in this article — which is precisely why a per-1,000 rate is a poor guide to this decision. If you want the operational substance behind those last two lines, along with package limits, cold starts, memory provisioning and the GB-second arithmetic, we worked all of it through for the serverless case in running Puppeteer on AWS Lambda.

Scenario 1: about 500 captures a month

A side project. A small SaaS generating Open Graph images for its public pages. Maybe a nightly capture of a dozen dashboards.

Managed: the free tier's 50 requests won't cover it, so this is Pro at €7 a month, €84 a year. Effective rate at 500 used out of 1,000 included: €14 per 1,000. That's an unimpressive per-unit number and an entirely irrelevant one, because the absolute figure is €7.

Self-hosted: at this volume the compute is close to noise. You could run 500 captures a month on a small always-on instance, or on a function that's idle 99.9% of the time, and the infrastructure bill would plausibly land in the same neighbourhood as Pro — possibly under it. It still isn't close, and the reason has nothing to do with infrastructure. Standing the thing up at all costs more than €84 buys, on any generous reading of how long it takes — and the build is the cheap half, because from then on the upgrades and the incident calls are yours for as long as the feature lives.

Verdict: managed, decisively. Not because the compute is expensive but because the compute isn't the cost. At 500 captures a month you are choosing between paying €84 a year and owning a browser fleet in exchange for saving some fraction of €84 a year. There is no version of that trade that works out.

Scenario 2: about 5,000 captures a month

A real product feature. Link previews for user-submitted URLs, PDF exports of reports, a visual QA pass on every deploy across a few dozen pages.

Managed: Pro's 1,000 doesn't reach, so this is Ultra at €20 a month, €240 a year. Effective rate at 5,000 used: €4 per 1,000, against a floor of €1.33 if you grew into the full 15,000. Which means the next three-fold increase in volume is free, and that headroom is worth something on its own — a feature that takes off doesn't trigger an infrastructure conversation.

Self-hosted: this is where compute stops being noise and where honest comparisons get interesting. Depending on your provider, your region, your page weight and how well you keep instances busy, raw compute for 5,000 renders a month can genuinely come in under €20. That result is real and it would be dishonest to bury it: measured on machines alone, self-hosting can win at this volume. What that measurement leaves out is that you'd be running a fleet that has to absorb bursts, with storage accumulating, egress metered, and a browser stack to keep current — all to compete with a €240 annual line item. One incident consumes the entire yearly saving. Two consume several years of it.

Verdict: managed, unless someone in your organisation already runs a browser fleet. That exception is real and worth naming: where rendering infrastructure is already a named team's responsibility, with rotations and runbooks that would exist whether or not you needed screenshots, bolting captures onto it is close to free and the comparison genuinely changes. Outside that case, what you're really deciding is whether to open a new operational surface for something that sits at the edge of your product — and operational surfaces without a clear owner have a habit of becoming everyone's problem at the worst possible moment.

Scenario 3: about 50,000 captures a month

A monitoring platform capturing a few thousand tracked pages daily. A web archive. An agency running a large site inventory on a schedule.

This is the volume where the answer stops being automatic, and it deserves to be stated plainly rather than spun.

Managed: 50,000 a month sits above the published grid — Mega AI's 30,000 requests is the largest published allowance — so none of the per-1,000 figures earlier in this article describe it, and projecting the curve past its last published point would be inventing a number rather than reporting one. For a volume like this the honest instruction is to start from the published plans — they top out at 30,000 requests, with overage handling layered on top — and work out your own exposure from there rather than from anything I could put in a blog post. Which means the interesting column in this scenario is the other one.

Self-hosted: this is the first scenario where volume works for you rather than against you. Fifty thousand renders a month is enough sustained load to keep machines occupied instead of idling, so you're paying for capacity you're actually consuming. The bigger shift is what happens to the fixed half of the bill. The engineer-week a year of browser upkeep is the same engineer-week at 50,000 captures as at 500 — you just divide it across a hundred times more output, and a maintenance burden that was ruinous per screenshot in scenario one becomes a rounding error here. What's left is a bill that moves with capture count, which is a shape a large operation can forecast and optimise.

Verdict: it depends, and the deciding factors are usually not cost. Three questions settle this more reliably than the spreadsheet does.

Where is the page allowed to be rendered? Internal tools, anything behind your own authentication, anything carrying personal data that cannot cross an organisational or jurisdictional boundary — that constraint outranks every figure on this page and points at a browser inside your own perimeter. It's a compliance answer, not an economic one.

How much of the browser do you actually need? For the large majority of workloads, a URL in and an image out is the entire requirement. The exceptions are specific and you'll know if you're one of them: driving a single session through several dependent steps, holding a frozen browser build so that a rendering bug stays reproducible for months, or speaking to the debugging protocol yourself. If that describes your workload, the browser has to be yours, and no per-1,000 rate changes that.

How spiky is the load? Machines you own can clear a backlog in one wide burst, at a width no plan tier will sell you. What they cannot do is make the far end faster — the sites you capture have their own tolerance, and going past it converts a fast run into a run full of errors, which is why bounded concurrency patterns earn their keep either way.

If all three answers come back mild, then at 50,000 a month it's close enough that "who maintains it" is the better tiebreaker than "what does it cost".

What makes a capture cost more than the base rate

Whichever side you land on, the per-capture rate is a floor, not a forecast. Four things lift it.

Retries. Billing is per request, so budget your quota on attempts, not on URLs. A flaky target site, a page that occasionally times out, a transient network fault — each one turns one intended capture into two or three actual requests. If your job list is 4,000 URLs and 5% of them need a second attempt, your monthly figure is 4,200, not 4,000. Build the failure margin into the plan you pick, and handle backoff properly rather than hammering; the mechanics are in rate limits and retries for high-volume usage.

Duplicate captures of pages that haven't changed. Of everything on this page, this is the item worth fixing first — and the one teams postpone longest, because writing it feels like premature optimisation until the invoice says otherwise. A nightly job over a 1,500-page site where forty pages actually changed spent 97% of its quota re-rendering identical HTML. Skipping a re-render is the only optimisation that zeroes out every column simultaneously — request count, compute, storage and bandwidth all go to nothing at once — which is why it outranks any amount of instance tuning or format fiddling. The client-side caching pattern is a couple of hours of work that keeps paying back every month afterwards.

Full-page captures of very long pages. fullSize is a single boolean and it can multiply your storage and bandwidth by an order of magnitude. A 1280×720 viewport capture is under a megapixel; the same page rendered full-height at 12,000 pixels tall is more than sixteen times the pixel area, and the file scales roughly with it. That doesn't change the request count, but it changes every byte-metered line downstream: storage, egress, and the transfer cost of anything that consumes the images. Two mitigations, both cheap. Capture the viewport when the viewport is what you need — a link preview or an OG image does not need the footer. And pick the format deliberately rather than leaving it on the default: PNG is the right call for pixel-exact diffing, and WebP or JPEG are dramatically smaller when the image is going into a report or a web page. The trade-offs are laid out in PNG vs JPEG vs WebP.

AI, when your workflow calls a model directly. Worth separating two cases. The v3 analyze endpoint's enableSummary and enableQuality outputs come back in the same response as the capture and count as one request against your plan. But if you've built a pipeline that captures a page and then hands the HTML or the image to a model provider yourself — the common shape in n8n and similar tools — that model call is billed by the provider, on their token pricing, entirely outside your capture quota. It's a second bill, it scales with page size rather than page count, and it's easy to forget until it arrives.

The feature floor can decide before the volume does

One more thing that catches people running the numbers purely on request counts: some capabilities are tier-gated, so the pages you need to capture can set your plan floor regardless of how few captures you make.

Free and Pro both cover PDF rendering, PNG/JPEG/WebP/HTML output, full-page capture, hiding cookie banners and ads, and hiding specific HTML elements by selector — which is genuinely most of what most captures need. Ingesting custom JavaScript (javascriptCode, for pages that need a scroll nudge, a modal dismissed, or a state set before capture) starts at Ultra, which also adds email support. Automatic DOM-ready detection (waitForDom) and AI webpage analysis and quality (enableSummary, enableQuality) are Mega AI, along with priority support.

So if your targets are the kind of client-rendered pages that only cooperate with an injected script, your floor is Ultra at €20 even at 300 captures a month, and the per-1,000 arithmetic stops being the deciding input. Check the pricing page against the parameters your captures actually need before you size on volume alone.

How to run this for your own case

Five lines, in this order:

1. Attempts per month, not URLs. Take your URL count, multiply by your schedule frequency, add a retry margin.
2. Subtract the duplicates. Decide now whether unchanged pages get re-captured, because it commonly changes the figure by a large multiple.
3. Pick the plan on the parameters, then the volume. Feature gating first, request count second.
4. For the self-hosted column, fill in every line above. The five headings expand into seven rows, because compute and memory scale differently and bandwidth is metered in both directions: compute, memory-driven concurrency, ingress, egress, storage plus its growth curve at month 24, browser upgrade time, and on-call. Use your provider's published rates. Any column missing the last two rows is not a comparison.
5. Convert the engineering lines into money at your own loaded day rate, and put them in the same table as the infrastructure. That's the whole exercise. Everything else is rounding.

Do that honestly and the answer usually falls out on its own: below a few thousand captures a month it isn't close, in the mid tens of thousands it's a genuine judgement call, and above that the questions that matter are about control and data residency rather than cost.

If your arithmetic lands on the managed side, run 50 captures against your own pages on the Snapshot Site free tier first. Real latency and real file sizes are worth more than any figure on this page when you're the one committing to a number.