Screenshot API Pricing for Full-Page Captures vs. Viewport Screenshots

Short answer: ScreenshotOne lists full-page screenshots on its Basic, Growth, and Scale plans, and its pricing page does not show a separate full-page surcharge. Its listed monthly prices are $17 for 2,000 screenshots, $79 for 10,000, and $259 for 50,000, with additional usage charged at different rates by plan. That is ScreenshotOne’s pricing, not an industry-wide rule: check each provider’s current terms before estimating your bill.

A viewport screenshot captures the content visible within the browser’s configured width and height. A full-page screenshot captures content beyond that initial window. The capture mode can affect rendering time and reliability, especially on long pages or pages that load images as you scroll, even when the provider does not list a different price for it.

1. What is the difference between a viewport and a full-page capture?

A viewport capture is a picture of the browser’s visible content area at the selected viewport dimensions. ScreenshotOne documents a default viewport of 1280 × 1024 pixels; its width and height options let you change that. A full-page capture extends beyond the visible area to include the longer document. On ScreenshotOne, use full_page=true; the option defaults to false. ScreenshotOne’s options documentation describes the viewport and full-page settings.

Capture mode	What it includes	Useful for
Viewport	The visible browser area at the chosen viewport size	Above-the-fold previews, responsive checks, fixed regions
Full page	The page beyond the initial viewport, often down to the document’s end	Long-form pages, complete page archives, page review

Full-page does not mean the rendered layout is independent of viewport width. A narrow width can trigger a mobile layout, while a wider width can show different navigation and columns. Choose the viewport based on the layout you want to capture.

2. ScreenshotOne pricing for full-page and viewport screenshots

At the time of research, ScreenshotOne’s listed monthly pricing was:

Plan	Monthly price	Included screenshots	Request rate	Extra screenshot	Full-page listed?
Free	$0	Up to 100/month	Not stated in the researched plan summary	Not stated	Verify current terms
Basic	$17/month	2,000/month	40 requests/minute	$0.009	Yes
Growth	$79/month	10,000/month	80 requests/minute	$0.006	Yes
Scale	$259/month	50,000/month	150 requests/minute	$0.004	Yes

The pricing page lists full-page screenshots on its paid plans and does not show a separate full-page price. It also says failed requests with HTTP, browser, or network errors do not count, and cached responses served from cache do not count; a cache miss that triggers a render can count. A successful render can still count even if the resulting image has a visual problem. Prices exclude VAT. These are vendor-published terms, not a market average. Check ScreenshotOne’s current pricing page before choosing a plan, since limits and prices can change.

Do not assume the same billing model at another provider. Compare the capture modes and included volume, plus what happens with overages, failed requests, and cache hits. Browserless documents full-page capture and controls such as viewport size and selector-based capture, but the research here does not establish a comparable current Browserless price schedule. Browserless’s screenshot API documentation describes its capture options.

3. How to estimate your monthly cost

1. Estimate rendered captures. Count the unique page states you expect to render in a typical month. If your workload mixes viewport and full-page captures, count both.
2. Check the included allowance and rate limit. Allowance determines the included monthly volume; requests per minute limits how quickly you can submit work.
3. Estimate overage separately. For a paid ScreenshotOne plan, a simple estimate is plan price + max(0, billable renders − included renders) × extra rate. Confirm actual billing definitions and limits on the live pricing page.
4. Account for caching. A cache hit served without a new render may not count under the stated ScreenshotOne terms; a miss or expired item that starts a render can count. Do not assume all providers treat cache the same way.
5. Include retries and quality checks. A failed request is treated differently from a successful render that has missing content. Your application may need to retry or flag the latter even if the request itself completed.

For example, 12,000 billable monthly renders on the listed Growth plan would mean 2,000 above its 10,000 included screenshots. At the listed $0.006 extra rate, the illustrative total would be $79 + (2,000 × $0.006) = $91 before any applicable tax. This assumes those renders are billable under the provider’s current rules; verify them before budgeting.

4. Request a viewport or full-page screenshot

Below are runnable examples using ScreenshotOne’s documented endpoint and full_page=true. These examples use a placeholder access key. Keep that key on a trusted server or in a secret manager; a key embedded in a public browser application or shared URL may be exposed. Use HTTPS. ScreenshotOne supports GET and POST requests and documents the access key as a query parameter, JSON value, or X-Access-Key header. See its getting-started guide for request and response details.

cURL

curl -G "https://api.screenshotone.com/take" \
  --data-urlencode "url=https://example.com" \
  --data-urlencode "access_key=YOUR_SCREENSHOTONE_ACCESS_KEY" \
  --data-urlencode "full_page=true" \
  -o full-page.png

For a viewport screenshot, omit full_page=true. To explicitly set viewport dimensions, add parameters such as viewport_width=1280 and viewport_height=1024.

Python

import requests

params = {
    "url": "https://example.com",
    "access_key": "YOUR_SCREENSHOTONE_ACCESS_KEY",
    "full_page": "true",
    "viewport_width": 1280,
    "viewport_height": 1024,
}
response = requests.get(
    "https://api.screenshotone.com/take",
    params=params,
    timeout=90,
)
response.raise_for_status()

with open("full-page.png", "wb") as image_file:
    image_file.write(response.content)

Node.js

import { writeFile } from "node:fs/promises";

const query = new URLSearchParams({
  url: "https://example.com",
  access_key: "YOUR_SCREENSHOTONE_ACCESS_KEY",
  full_page: "true",
  viewport_width: "1280",
  viewport_height: "1024",
});

const response = await fetch(
  `https://api.screenshotone.com/take?${query}`,
  { signal: AbortSignal.timeout(90_000) },
);

if (!response.ok) {
  throw new Error(`Screenshot request failed: ${response.status} ${await response.text()}`);
}

await writeFile("full-page.png", Buffer.from(await response.arrayBuffer()));

These samples save the response bytes to a PNG filename. If you request a different output format, use a matching file extension and inspect the response’s Content-Type rather than assuming the server returned an image. The API can return JSON for errors; check the HTTP status before saving a response as an image.

5. Options that affect full-page output and cost planning

The options below are documented by ScreenshotOne. They affect capture behavior and resource use; the cited pricing page does not state a separate price for each option. Confirm current parameter names, constraints, and billing before relying on them.

Option or setting	What it changes	When to use it
full_page	Enables capture beyond the initial viewport; default is false.	Use true when you need the long page, rather than just the visible area.
viewport_width, viewport_height	Sets the browser viewport used for layout. Width is especially important to the final full-page layout.	Set dimensions to match the target desktop or mobile layout. The documented defaults are 1280 × 1024.
full_page_scroll	Scrolls down and back up to trigger content loading; full-page mode enables it automatically unless overridden.	Keep it enabled when the page lazy-loads content. Disabling it can reduce rendering time but may omit content that only appears after scrolling.
full_page_algorithm	The default method captures the expanded page; by_sections scrolls section by section and combines the captures.	Try by_sections when the default produces rendering issues or a complex page needs scroll-triggered loading.
full_page_scroll_by, full_page_scroll_delay	Adjusts scroll step and timing for section-based or scroll-triggered content.	Try smaller steps or longer delays if lazy images are missing. More scrolling and waiting can increase latency.
full_page_max_height	Caps the height of a full-page image.	Use a limit to prevent runaway captures on infinite-scroll pages or unusually long documents.
device_scale_factor	Sets pixel density; ScreenshotOne documents values from 1 to 5, including fractional values.	Use a higher value when you need denser output, while accounting for larger images and processing.

ScreenshotOne’s full-page guide explains that the section-by-section method can trigger lazy-loaded elements as the page scrolls, but scrolling cadence and delay matter. Its options reference documents parameters including maximum height and viewport controls. More conservative waits or higher pixel density can improve completeness or sharpness, but may increase response time or output size.

6. Reliability, performance, and cost trade-offs

• Viewport captures are usually a smaller job. They include less page area and may avoid scrolling through below-the-fold content. If all you need is a preview or layout check, avoid requesting full-page output without a reason.
• Full-page captures involve more than image height. A long page may need scrolling to trigger lazy loading. Sticky headers, animations, infinite scrolling, and delayed content can affect the result.
• Reliability needs visual checks. A successful HTTP response does not guarantee that every image or section appeared. For important captures, validate image dimensions and inspect representative outputs.
• Concurrency and rate limits are separate from monthly volume. ScreenshotOne lists 40, 80, and 150 requests per minute for Basic, Growth, and Scale respectively. Queue work and apply backoff when you approach a provider’s limit.
• Cache policy changes effective rendering volume. Stable URLs and settings are easier to reuse from cache; changing query parameters or allowing cache entries to expire can require new renders. Confirm cache behavior and TTL with the provider.
• Image size has downstream costs. Taller captures and higher device scale factors create more pixels to transfer, store, and process. Resize or compress when the consuming system does not need the original dimensions.

For provider comparisons, line up the same workload: number of distinct URLs, viewport dimensions, full-page share, desired format and density, retries, cache behavior, and peak request rate. A low per-capture rate can still be a poor fit if the API lacks the capture controls or reliability your pages require.

7. Troubleshooting common full-page capture problems

Symptom	Likely cause	What to try
Only the visible area appears	The request omitted full_page=true, or the chosen endpoint or parameter is incorrect.	Check the final encoded request and confirm the provider’s full-page option and endpoint.
Images or sections are missing below the fold	Content loads only after scrolling, or the scroll is too fast for the page.	Enable full-page scrolling; try section-based capture, smaller scroll steps, or a longer scroll delay.
The page is cut off or extremely tall	Infinite scrolling or an unusually long document keeps extending the page.	Set a maximum full-page height if supported, or capture a bounded region or specific section.
The mobile layout is captured when desktop was expected (or vice versa)	The viewport width triggered a different responsive breakpoint.	Set the viewport width explicitly and keep it consistent across comparisons.
The output looks blurry or is too large	Pixel density is too low for the intended display, or too high for the storage and transfer budget.	Adjust device scale factor to the actual use case; validate image dimensions and file size.
The client saves an error as an image	The API returned an error status or JSON body, but the client wrote it to an image file without checking.	Check HTTP status and response content type before saving; log the provider’s error body securely.
Requests fail intermittently or take too long	Target pages are slow, provider rate limits are reached, or a long-page render exceeds the client timeout.	Use a reasonable client timeout, queue requests, back off on rate limits, and retry transient errors with a limit.
API key appears in logs or browser code	The key was placed in a public client or exposed URL.	Move calls behind your server, restrict access to secrets, and rotate a key if it has been exposed.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. A single GET request can return an image or PDF, and its parameter names are compatible with those used by other screenshot APIs, which can make switching straightforward. Cookie banners are accepted like a visitor and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. Its MCP server gives AI agents tools for screenshots, page info, and PDF capture. Learn about ScreenshotNeo.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

See the ScreenshotNeo API documentation for request details. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up free and get 1,000 screenshots a month with no card.

9. FAQ

Does full-page capture always cost more than viewport capture?

No universal pricing rule follows from the available evidence. ScreenshotOne lists full-page screenshots on its paid plans without a separate full-page price, but another provider may price or meter captures differently.

Is full-page mode the same as scrolling screenshots?

Not necessarily. Providers may implement full-page capture by expanding the rendered page or by scrolling, capturing sections, and combining them. Check the provider’s documentation because the method can affect lazy-loaded content and output quality.

Should I choose a plan by monthly volume alone?

No. Compare the rate limit, overage rules, cache treatment, capture controls, and whether failed or visually incomplete results count. Those terms can matter as much as the headline allowance.

Can I use ScreenshotNeo if I need full-page captures?

ScreenshotNeo supports full-page capture with lazy images loaded. Its documented plan facts state that all features are available on every plan; consult the API documentation for request parameters.