ScreenshotNeo

BlogComparisons

ShrinkTheWeb Bulk Website Screenshots: Batch Capture Options

ShrinkTheWeb currently announces a relaunch, so its bulk API details are unconfirmed. Compare documented batch options and build a reliable URL capture workflow.

By the ScreenshotNeo team4 October 20269 min read

If you are looking for a ShrinkTheWeb bulk website screenshot API, its current official homepage says “Shrink The Web is Relaunching Soon!” and does not publish current batch endpoints, limits, pricing, or account availability. Treat those details as unconfirmed until the relaunch documentation appears. A historical Drupal module is not evidence of the service’s current capabilities. ShrinkTheWeb’s homepage is the place to recheck for current information.

For a working batch workflow today, the sourced options to evaluate are ScreenshotNeo for hosted captures, Capture’s signed batch API when you can provide S3-compatible storage, url2image for its documented URL-list-to-ZIP workflow, and shot-scraper for local YAML-driven capture. Their documented options are not a quality or speed ranking; test representative pages with your own settings.

What is known about ShrinkTheWeb today

The official homepage announces a relaunch but provides no current bulk API documentation, capacity, pricing, or account terms. Do not rely on historic endpoint examples or quote old capacity and pricing as current.

The ShrinkTheWeb Drupal project page describes a module that used the service API for cached screenshots and historically included “Refresh ALL” and a notification callback. The project page labels the module unsupported and obsolete, and says it appeared unsupported as of 2022-01-31. That status applies to the Drupal module; it does not establish whether the screenshot service itself is operating or what it will offer after its announced relaunch. Drupal project status and historical features.

Batch capture options to investigate

Option How batch input and output work Constraints to check
ScreenshotNeo Hosted screenshot API; supports bulk capture of up to 100 URLs per call. Each URL can use the API’s capture options. Check the documentation for request parameters and response behavior. Its free plan includes 1,000 shots/month; paid plans start at $5 for 3,000.
Capture Documented batch endpoint accepts an array of URL requests and can send a webhook notification. Requires an S3-compatible bucket for output and HMAC-SHA256 request signing with an API secret. The reviewed documentation does not state a numeric maximum batch size.
url2image Accepts pasted or uploaded URL lists or a JSON array, then returns a ZIP with an image per URL, a manifest, and a failure CSV. Vendor documentation states up to 500 URLs per batch and fourteen-day screenshot retention. Confirm live pricing and terms before choosing it.
shot-scraper Local command-line workflow: define multiple jobs in YAML and run shot-scraper multi. You operate the machine, browser setup, storage, retries, and scheduling. Its manual documents dimensions, selectors, waits, and authentication contexts.

Sources: Capture batch API documentation, url2image batch workflow and published terms, and shot-scraper 1.4 multi-capture documentation. Vendor-published capacity, retention, and pricing are claims from those vendors, not independent measurements.

How to design a reliable batch

  1. Normalize and validate the URL list. Require absolute HTTP or HTTPS URLs, remove duplicates if duplicate captures are not useful, and retain a stable input ID for every row.
  2. Choose a batch size the service documents. url2image states 500 URLs per batch and ScreenshotNeo supports 100 URLs per call. Capture’s reviewed batch page gives no numeric maximum, so confirm it before submitting large jobs. For a local process, start with small chunks to bound memory and recovery time.
  3. Define capture settings consistently. Record viewport, output format, full-page behavior, waits, and authentication needs. Use the same settings when comparing services.
  4. Choose result delivery before submission. A ZIP is convenient for a download, S3 fits workflows that already use object storage, and a local directory suits a self-managed job. Keep the URL-to-output mapping in a manifest.
  5. Make completion recoverable. Persist each job ID or input ID, save webhook events, and retry only missing or failed URLs. Avoid restarting a full batch because a few pages failed.
  6. Run a representative pilot. Include pages with redirects, consent banners, slow assets, long content, and any login requirement. Review both successful images and failure records before scaling up.

DIY: run multiple captures locally with shot-scraper

shot-scraper is useful when the capture must run in your environment and you want to own the output files and job orchestration. Install it using the instructions for your environment in its documentation, then create a YAML job file. A minimal multi-job file looks like this:

- url: https://example.com/
  output: screenshots/example-home.png
  width: 1365
  height: 900
- url: https://example.org/
  output: screenshots/example-org.png
  width: 1365
  height: 900

Run the jobs with:

shot-scraper multi jobs.yml

The YAML file is the input manifest: keep output paths unique and retain the source URL alongside each result. The documented multi workflow supports capture controls such as dimensions, selectors, waits, and authentication contexts. Consult the versioned manual for exact YAML keys and authentication setup rather than guessing field names.

For a production job, divide a large input list into manageable YAML files or chunks, run them under a scheduler, capture each process exit status, and reconcile expected output paths against the input manifest. Add retries around individual failed jobs, not the entire list. If pages require an authenticated session, configure and protect the authentication context as described in the manual; do not commit session state or credentials to source control.

Hosted alternatives and request examples

Capture batch API

Capture documents POST https://cdn.capture.page/batch-image/[your-api-key]. Its request uses an x-req-signature computed with HMAC-SHA256 and an API secret; the payload is an array of URL requests, with an optional webhook notification URI. Configure an S3-compatible destination for the resulting images. Follow its current request schema and signing instructions exactly: the reviewed documentation establishes these requirements but does not establish a maximum batch size. Do not invent a signature header value or assume an unsigned example will work.

url2image batch workflow

url2image documents a JSON-array API option as well as pasted or uploaded URL lists. Its vendor page states a maximum of 500 URLs per batch, a ZIP containing images, a manifest.json with page title, final URL, status, and dimensions, and a not-rendered.csv for failures. It also says a URL is retried once and its credit is returned if no screenshot is produced. These are vendor statements; verify the current interface and terms before building around them. The page lists ten free screenshots each month, prepaid credits that do not expire, published tiers, and fourteen-day retention. Check the live page for prices rather than embedding potentially stale amounts in code.

Or skip the browser setup

ScreenshotNeo is the hosted option to try first for this workflow: it supports bulk capture of up to 100 URLs per call, and its lowest paid plan is $5 for 3,000 shots. One request captures a URL; the same endpoint and parameters are documented for the product API. See the ScreenshotNeo API documentation.

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

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

These examples capture one URL. For bulk jobs, use the documented bulk request format and 100-URL call limit in the docs. Cookie banners, popups, and chat widgets are removed before the shot; each cleanup step can be disabled. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. The product also has an MCP server with take_screenshot, get_page_info, and capture_pdf tools for AI agents. One thousand screenshots per month are free with no card, and paid plans start at $5 for 3,000; yearly billing gives two months free. Sign up for ScreenshotNeo’s free 1,000 screenshots per month.

Compare options against your actual workload

  • Submission limits: confirm maximum URLs, payload size, concurrency, and rate limits. Only use a stated limit as a planning value; recheck it when the provider updates its docs.
  • Storage and delivery: decide whether you need files in your own bucket, an archive and manifest, or local paths. Capture requires S3-compatible storage; url2image describes ZIP output.
  • Failure accounting: establish whether the service retries, reports per-URL errors, or returns unused credits. Save failure records so reruns are targeted.
  • Page behavior: verify support for redirects, authentication, cookies, waits, lazy-loaded content, and the desired viewport on a small pilot.
  • Retention and privacy: understand how long outputs remain available and who can access the storage destination. url2image states fourteen-day retention; check current terms for all providers.
  • Price at expected volume: calculate successful captures and retries, not just submitted URLs. Include your own storage, browser compute, and engineering time for self-hosted workflows.
  • Quality and speed: there is no common benchmark in the cited material. Compare tools on the same representative URLs and settings.

Performance, reliability, and cost

Batching reduces request orchestration overhead, but it does not make a slow or script-heavy page render faster. Large jobs can increase the time before you discover a configuration mistake and make recovery harder. Chunk work, store progress durably, and use webhooks or job polling according to the provider’s documented delivery model.

For local shot-scraper jobs, browser processes and page assets consume your machine’s CPU, memory, network, and disk. Bound concurrency to the capacity you observe, and write outputs to storage with adequate space. For hosted services, check limits and billing rules in current vendor documentation. url2image’s published retry and credit behavior is vendor-reported; Capture’s reviewed batch documentation does not provide a price comparison. Do not infer a cost or speed advantage without measuring your own workload.

Improve reliability by keeping an immutable input manifest, mapping each URL to a stable ID, recording requested settings and result status, and retrying transient failures with a limit. Separate invalid URLs, access-denied pages, and rendering timeouts from successful captures. Treat webhook delivery as asynchronous and make the handler idempotent so duplicate notifications do not create duplicate records.

Troubleshooting

Symptom Likely cause What to do
ShrinkTheWeb endpoint or batch limit cannot be found The official site currently announces a relaunch and does not publish those details. Do not assume legacy endpoint behavior. Recheck official documentation after the relaunch or choose a documented workflow.
Capture rejects a batch request Incorrect HMAC signature, malformed request array, or missing S3-compatible destination configuration. Recompute the signature per current instructions, validate the payload, and verify bucket setup and permissions.
Capture accepts work but no files appear in the bucket Destination configuration or write permissions may be wrong; processing may still be pending. Check the job notification for errors and confirm the configured bucket can accept writes.
url2image reports a URL as not rendered The page may have failed to load or render within the service’s workflow. Use not-rendered.csv to isolate failures, inspect the URL manually, then retry only those URLs.
shot-scraper cannot find an output file Output directory is missing, path is malformed, or the job failed before writing. Check the command’s exit status and logs, create the parent directory, and verify each YAML output path.
Screenshot shows a loading state or incomplete page The capture happened before client-side rendering or lazy assets finished. Use the provider’s documented wait controls or selector wait; test a longer wait on the affected URL before applying it globally.
Protected page is blank or redirects to sign-in The capture does not have the required cookies or authentication context. Configure the supported authentication mechanism, protect credentials, and test against a page you are authorized to access.
Large batches are slow or difficult to recover Batch size is too large for the workflow or individual pages have uneven render times. Split into chunks, persist per-URL status, and retry failed entries instead of resubmitting completed captures.

FAQ

Is ShrinkTheWeb currently accepting bulk screenshot jobs?

The retrieved official homepage announces a relaunch but does not confirm current account availability or job submission. Check the official site for updated information.

Does the Drupal module’s obsolete status mean ShrinkTheWeb shut down?

No. The dated status applies to the Drupal module project and does not establish the service’s current operational status.

Which option should I use for hundreds of URLs?

Choose based on documented limits, output handling, and your operating model: url2image states up to 500 URLs per batch, ScreenshotNeo supports up to 100 URLs per call, Capture’s reviewed page has no numeric maximum, and shot-scraper runs jobs locally. Confirm live limits before submitting production work.

Can I compare services by published batch size alone?

No. Batch size says little about rendering accuracy, completion time, or failure recovery. Run a controlled pilot with the same pages and settings.