ScreenshotOne vs. ScreenshotAPI vs. CaptureKit: Comparison

If you need the lowest listed paid entry price, CaptureKit starts at $7/month for 1,000 credits. ScreenshotAPI.net lists a $9/month plan for 1,000 screenshots. ScreenshotOne starts at $17/month for 2,000 screenshots, with 40 requests per minute and a broad published feature set that includes PDF, caching, S3 uploads, webhooks, and signed links. The right choice depends on your expected volume, request rate, rendering controls, storage, and whether you need bulk or scheduled workflows.

For a fourth option, ScreenshotNeo is the first alternative to try when clean output and predictable billing matter: it removes consent banners, popups, and chat widgets before capture, and says bot checks, blank pages, failed loads, and cache hits are not billed. Its free plan includes 1,000 shots a month, with no card. See ScreenshotNeo.

1. Comparison at a glance

Service	Published entry	What stands out	Consider it when
ScreenshotNeo	Free: 1,000 shots/month; Starter: $5 for 3,000	Consent and overlay cleanup, verdict and billing headers, MCP server	You want clean shots, transparent outcomes, or agent workflows
CaptureKit	100 free credits; $7/month for 1,000 credits	Browser playground, bulk capture, clean renders, page content features	Low paid entry price or an interactive setup matters
ScreenshotAPI.net	100 free captures/month; $9/month for 1,000 screenshots	Single endpoint, bulk and scheduled capture positioning	You want a lower-cost general API or scheduled/bulk workflows
ScreenshotOne	100 free screenshots; $17/month for 2,000	Broad production controls, storage, webhooks, signed links, PDF	You need a broad set of rendering and delivery features

These are published plan figures, not a benchmark of equivalent workloads. Credit definitions, overage rules, cache behavior, and feature availability can change. Check each provider’s current plan page before committing budget.

2. Pricing and volume

ScreenshotOne pricing

ScreenshotOne publishes 100 free screenshots, then Basic at $17/month for 2,000 screenshots and 40 requests per minute; Growth at $79 for 10,000 and 80 requests per minute; and Scale at $259 for 50,000 and 150 requests per minute. Its pricing page lists extra-use rates by plan and says only successful requests are charged. Cache behavior can affect whether a render consumes usage; read the plan terms and usage documentation for your account.

Its published feature set includes PDF, PNG, WebP, JPEG, HTML rendering, full-page capture, caching, S3 uploads, webhooks, signed links, and stealth mode. Higher tiers list location selection, scrolling screenshots, video generation, GPU rendering, and priority support. See ScreenshotOne pricing and how its credits work.

ScreenshotAPI.net pricing

The comparison research reports an entry plan of $9/month for 1,000 screenshots. Its feature page describes 100 free captures per month and predictable per-capture billing. Comparison material describes full-page screenshots, PNG/JPEG/WebP/PDF, blocking, bulk capture, and scheduled capture; scrolling and video are described as higher-plan features. The public pricing page can show promotions, so verify the price and included allowance at checkout. See ScreenshotAPI.net pricing.

CaptureKit pricing

CaptureKit’s pricing page lists 100 free credits and a $7/month Starter plan with 1,000 credits. The free and Starter plan feature list includes screenshot output in PNG, JPEG, WebP, and PDF, caching, cookie banner blocking, S3 upload, a page content API, integrations, stealth mode, and an AI summarizer API. Credits are not necessarily interchangeable with another provider’s screenshot unit; confirm what actions consume credits. See CaptureKit pricing.

Compare effective cost, not just the headline

1. Estimate monthly successful captures, including scheduled repeats, retries, and multiple viewports per page.
2. Check whether failed navigation, anti-bot pages, cache hits, and visually incorrect output consume quota.
3. Compare included volume and overage rates at your likely usage, not only the smallest plan.
4. Check whether PDF, full-page output, storage, or async jobs consume extra credits.
5. Set a monthly hard limit or alert where the provider offers one, and decide what your application should do at quota exhaustion.

For example, a 1,000-page job rendered in desktop and mobile sizes is at least 2,000 render requests before retries or periodic recaptures. A plan that looks adequate by URL count may be undersized by actual render count.

3. Throughput and workload shape

Published per-minute limits are only one part of throughput. ScreenshotOne lists 40, 80, and 150 requests per minute on the cited paid tiers. ScreenshotAPI.net lists 20 requests per minute on its Essential plan and higher limits on larger plans. The comparison dossier does not give a comparable CaptureKit request-per-minute limit, so ask or check its current documentation rather than assuming unlimited concurrency.

For a one-off request from a user waiting on a preview, a synchronous endpoint is usually straightforward. For large batches, recurring monitoring, or a user-facing application with unpredictable bursts, investigate queueing, async jobs, webhooks, bulk endpoint size, retry behavior, and rate-limit responses. The providers’ published positions differ: ScreenshotAPI.net describes bulk and scheduled capture; CaptureKit lists bulk capture in comparison material; ScreenshotOne lists webhooks and storage workflows. Verify plan-specific details.

Keep a queue on your side when the product does not specify the exact concurrency semantics you need. Limit workers to a conservative rate, honor retry-after guidance if returned, and use exponential backoff with jitter for transient errors. Avoid retrying permanent URL or authentication errors.

4. Rendering controls and output

A screenshot is only useful if the rendered state matches the intended state. Compare these options against an actual representative page, not a feature checklist alone:

• Page extent: viewport-only, full-page, or scrolling capture.
• Target: whole page or a specific element.
• Viewport: dimensions, device presets, device scale, and mobile emulation.
• Timing: fixed delay, selector wait, network-idle condition, or page-specific readiness signal.
• Interaction: click controls, scroll, or run custom JavaScript before capture.
• Appearance: dark mode, custom CSS, hidden selectors, background transparency.
• Network and identity: headers, cookies, user agent, location, and blocked request types.
• Output: PNG, JPEG, WebP, PDF, dimensions, compression, and optional HTML/content output.
• Delivery: direct bytes, stored object, signed link, webhook, or cached response.

ScreenshotOne’s published list includes PDF and common image formats, HTML rendering, full-page capture, caching, S3 upload, webhooks, and signed links. ScreenshotAPI.net’s comparison material lists common image/PDF formats, blocking, bulk, and scheduled capture. CaptureKit’s official plan page lists common image/PDF formats and caching, plus content-oriented APIs. Feature names do not guarantee identical behavior; check how each provider handles lazy loading, sticky elements, overlays, and very long documents.

5. What to test before choosing

1. Pick representative pages. Include a static landing page, a JavaScript-heavy page, a long page with lazy images, and any page behind consent or authentication.
2. Fix the intended viewport and output. Use the same width, height, device scale, format, and full-page setting in each trial.
3. Define readiness. Decide what visible element or state means the page is ready. A generic delay can either waste time or capture too early.
4. Check output visually. Inspect missing images, fonts, sticky headers, cookie notices, dynamic widgets, and clipping. A successful HTTP response does not prove a useful image.
5. Run a burst and a batch. Observe latency, rate limits, failures, queue behavior, and webhook delivery with your expected job shape.
6. Calculate cost from outcomes. Count billable renders, cache hits, retries, and failed pages according to the provider’s own billing rules.
7. Review data handling. Determine whether URLs, screenshots, cookies, headers, and stored files contain sensitive data; configure retention and access accordingly.

Provider-authored response-time and uptime claims are not independent comparative benchmarks. The research dossier reports CaptureKit comparison claims of approximately 99.9% uptime and approximately seven-second average response time, but these should be treated as provider claims, not as a controlled head-to-head test. Test the URLs and regions that matter to your workload.

6. Request examples

Exact query parameter names and authentication differ by service. The examples below demonstrate the shape of an HTTP screenshot request; use each provider’s current API reference for a runnable provider-specific request and its required key parameter. Do not send a secret key in browser-side JavaScript.

cURL pattern

curl -G "https://YOUR_PROVIDER_ENDPOINT" \\
  --data-urlencode "url=https://example.com" \\
  --data-urlencode "format=png" \\
  -o page.png

Python pattern

import os
import requests

endpoint = "https://YOUR_PROVIDER_ENDPOINT"
params = {
    "url": "https://example.com",
    "format": "png",
    "access_key": os.environ["SCREENSHOT_API_KEY"],
}
response = requests.get(endpoint, params=params, timeout=90)
response.raise_for_status()
with open("page.png", "wb") as image_file:
    image_file.write(response.content)

Node.js pattern

const endpoint = "https://YOUR_PROVIDER_ENDPOINT";
const params = new URLSearchParams({
  url: "https://example.com",
  format: "png",
  access_key: process.env.SCREENSHOT_API_KEY,
});

const response = await fetch(`${endpoint}?${params}`, {
  signal: AbortSignal.timeout(90_000),
});
if (!response.ok) {
  throw new Error(`Screenshot request failed: ${response.status}`);
}
const bytes = new Uint8Array(await response.arrayBuffer());
await import("node:fs/promises").then(fs => fs.writeFile("page.png", bytes));

Replace the endpoint and parameters with the selected vendor’s documented values. Validate the response content type and status before writing bytes: error payloads may be JSON or text rather than an image.

7. Troubleshooting common capture failures

Symptom	Likely cause	What to try
Blank or half-rendered page	Capture happened before app hydration or content load	Wait for a stable selector or app-ready condition; use a short delay only if the page has no reliable readiness signal.
Missing images below the fold	Lazy-loaded resources never entered the viewport	Use full-page or scrolling capture if supported; test on the actual page and allow time for image loading.
Cookie panel or popup covers content	Consent state or overlay appears after initial load	Use a provider’s banner/popup blocking controls, or configure an explicit click/hide action where available.
CAPTCHA or access-denied screen	The destination blocks automated traffic or requires a human challenge	Do not treat a screenshot of the challenge as the page. Check the destination’s access rules and use an authorized route or allowlist.
HTTP 429 or quota error	Rate or monthly allowance was exceeded	Reduce worker concurrency, queue requests, back off, check usage, and adjust the plan or hard limit if appropriate.
Request times out	Slow origin, heavy scripts, blocked resources, or too-short client timeout	Increase the client timeout within reasonable limits; use async capture for long jobs; inspect the URL and readiness condition.
Image file contains an error message	Code saved a non-image response without checking status/type	Check HTTP status and Content-Type before writing; log a safe error body and request identifier if supplied.
Wrong page state behind login	Cookies or auth headers were missing, expired, or scoped incorrectly	Supply documented cookies or headers securely, verify their domain/path and expiry, and avoid exposing secrets in logs.
Full-page image is clipped or unusually tall	Very long document, fixed/sticky layout, or browser capture limit	Try element capture or scrolling slices; reduce scale or split the page into sections if supported.

8. Performance, reliability, and cost controls

Rendering cost and latency are affected by the destination page, image and script weight, viewport, full-page mode, waiting rules, and whether the result can be served from cache. A fixed long delay makes every request slower; a fixed short delay risks incomplete output. Prefer a page-specific selector or readiness signal when available, then set a timeout that leaves room for slow but valid pages.

Cache deterministic captures when the underlying page changes less frequently than your request rate. Include relevant render options in your cache key so that mobile and desktop, dark and light, or different authentication contexts do not collide. For signed links or stored screenshots, set access and expiry to match the sensitivity of the captured page.

Use bounded retries for transient network or provider errors, with backoff and jitter. Do not automatically retry a CAPTCHA, invalid URL, missing permission, or persistent page error on every worker cycle. Keep an idempotency key or your own job identifier so that a webhook retry cannot create duplicate downstream work.

Track success rate, capture duration, output size, cache hit rate, retries, and provider usage. A low listed per-capture cost can become expensive when every run includes several viewports, recurring schedules, retries, or full-page output. Recheck prices and quotas immediately before launch; the cited plans are current published snapshots and may change.

9. Or skip the browser setup

ScreenshotNeo makes one GET request to capture a URL and returns an image or PDF. See the ScreenshotNeo API documentation for the full option list.

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

There are matching Python and Node.js examples in the docs. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, failed loads, and cache hits are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

10. Recommendation by use case

Your priority	Shortlist	Why
Clean results and explicit page outcomes	ScreenshotNeo	Consent and common overlay cleanup, plus response headers that identify verdict and billing outcome.
Lowest listed paid entry	CaptureKit	$7/month for 1,000 credits on its published Starter plan; confirm credit consumption for your workflow.
Lower-cost general endpoint and scheduled/bulk positioning	ScreenshotAPI.net	Published entry is $9/month for 1,000 captures, with bulk and scheduled capture described in comparison material.
Broad production delivery controls	ScreenshotOne	Its published plan set covers caching, S3, webhooks, signed links, PDF, and higher-tier video/GPU options.

Start with two providers if the choice has meaningful operational consequences: run the same small representative workload, inspect output quality and failure semantics, then compare actual cost and integration effort. Do not select from a feature list alone.

11. FAQ

Which service is cheapest?

CaptureKit has the lowest listed paid entry price in this comparison: $7/month for 1,000 credits. Whether it is cheapest for your workload depends on how its credits map to your requested outputs and any higher-volume tier you need.

Are the free plans equivalent?

No. The cited offerings describe 100 free screenshots or captures for ScreenshotOne and ScreenshotAPI.net, and 100 credits for CaptureKit. ScreenshotNeo lists 1,000 free shots monthly without a card. Check renewal, limits, and feature restrictions on each current plan page.

Can these APIs replace Playwright or Puppeteer?

They can handle hosted page rendering when you need an image or document through an API. A locally managed browser remains useful when you need custom browser instrumentation, a private network, or complete control over the browser lifecycle.

Should I choose based on a claimed uptime or average response time?

Use vendor-published figures as claims, not as independently comparable measurements. Test your own URLs, regions, capture settings, and expected traffic pattern.