Wayback Machine Alternative: Screenshot API for On-Demand Capture

The Wayback Machine is the world's largest web archive — over 890 billion pages captured since 1996. It's a public good run by the Internet Archive, a nonprofit. For looking up how a website appeared five years ago, nothing else comes close. But developers who need to capture web pages programmatically — on demand, in specific formats, with content blocking or device emulation — hit the Wayback Machine's limitations fast. The APIs exist but weren't built for screenshot workflows. I run screenshotrun, so read this with that bias in mind. The technical details below are verifiable against the Internet Archive's public API docs and screenshotrun's documentation.

This comparison covers what the Wayback Machine does well, where its APIs fall short for capture workflows, how a screenshot API handles the same use cases differently, and when you should use both.

Archive lookup vs on-demand capture

The Wayback Machine stores historical snapshots of the web. When you look up a URL, you're browsing through captures that the Internet Archive's crawlers took at some point in the past — maybe yesterday, maybe 2003. You don't control when captures happen (unless you use Save Page Now), you can't control how they render, and the output is a reconstructed HTML page, not a screenshot image.

A screenshot API captures a URL right now, in the format you specify, with the rendering options you choose. Pass a URL, get back a PNG, WebP, AVIF, or PDF. The capture happens on demand — your code decides when to trigger it. No archive. No history. No public index. The image goes wherever you send it.

One product answers "what did this page look like in the past?" The other answers "what does this page look like right now, rendered exactly how I want it?"

The Wayback Machine's APIs

The Internet Archive exposes three main APIs. None of them are screenshot APIs, but developers sometimes try to use them as one.

CDX API returns metadata about captured pages — timestamps, HTTP status codes, MIME types, content hashes. It's a search index, not a capture tool. You can query which snapshots exist for a URL within a date range, filter by status code, deduplicate by content hash. Powerful for research. Useless for generating images.

Availability API checks whether a snapshot exists for a given URL near a given timestamp. Returns a single result — the closest match. No format control. No rendering options either. The response is a URL to a reconstructed web page, not a screenshot.

Save Page Now (SPN2) is the closest thing to an on-demand capture. You submit a URL, the Archive's crawler fetches it, and the result gets added to the Wayback Machine's index. You can request a screenshot alongside the page capture (capture_screenshot=1). But the process is asynchronous — you get back a job ID, then poll for completion. The screenshot is a byproduct of archiving, not the primary output. And the format is whatever the Archive chooses to store.

# Save Page Now — request a capture with screenshot
curl -X POST "https://web.archive.org/save" \
  -H "Authorization: LOW YOUR_ACCESS_KEY:YOUR_SECRET_KEY" \
  -d "url=https://example.com&capture_screenshot=1"

# Response: {"job_id": "abc123", "status": "pending"}
# Poll: https://web.archive.org/save/status/abc123

Compare that to a synchronous screenshot API call:

curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&format=webp&full_page=true&block_ads=true" \
  -H "Authorization: Bearer YOUR_API_KEY"
# Response: the image itself, immediately

One request, synchronous response, image in the format you specified. No polling. No job queue. The image arrives when your request finishes, not when the Archive's crawler gets around to it.

Comparison table

The Wayback Machine's rate limit problem

This is the issue that trips up most developers who try to build on Wayback Machine APIs. The Internet Archive doesn't publish hard rate-limit numbers. The CDX API tolerates sequential requests reasonably well, but fire too many in parallel and you'll get 429 errors. SPN2 is more tightly limited — it's a write operation that triggers a real crawler, so the Archive restricts how many captures you can request per hour.

After a major cyberattack in October 2024, the Internet Archive tightened rate limits significantly. Community tools built on the API now ship with self-imposed throttles because the actual limits are discovered through trial and error. If you're building a production system that depends on consistent API behavior, unpublished rate limits that change without notice create reliability problems you can't plan around.

screenshotrun publishes its rate limits in the documentation. You know exactly how many requests per second your plan supports. If you exceed the limit, the response tells you so with a clear status code. No guessing, no silent degradation.

When the Wayback Machine is the right tool

The Wayback Machine does things no screenshot API can replicate.

Historical lookups are the obvious case. "show me apple.com in 2005" Only the Wayback Machine has that data. If you need to research how a site evolved over years or decades, the CDX API gives you a timeline of every captured snapshot, filterable by date range, status code, content hash. No commercial screenshot service maintains an archive of the entire web going back to 1996.

Link rot recovery is another strong use case. A page you linked to returns 404 now. The Availability API checks if the Wayback Machine has a copy. Academic researchers, journalists, SEO teams recovering broken backlinks — this is core Wayback Machine territory. The capture already exists in the Archive. You're just looking it up.

Legal and evidentiary research benefits from the Archive's timestamp credibility. A Wayback Machine snapshot carries weight in legal proceedings because the Internet Archive is a recognized nonprofit with established archival processes. (For new captures that need cryptographic proof of what a page showed at a specific moment, screenshotrun's certified screenshots take a different approach — they embed a hash chain that proves the image wasn't modified after capture.)

The Wayback Machine is free. That matters. For researchers, journalists, nonprofits, students — anyone who needs historical web data, the cost barrier is zero beyond the time it takes to learn the APIs.

Where developers outgrow the Wayback Machine

The pain shows up when you try to use the Wayback Machine as a capture service rather than an archive lookup.

No rendering control. The Wayback Machine stores pages as they were crawled — whatever the crawler's browser rendered at the time. You can't specify a viewport, device type, dark mode, retina resolution. You can't block ads or cookie banners. You can't inject CSS or JavaScript to modify the page before capture. The archived version is what you get, rendering quirks included.

JavaScript-heavy sites archive poorly. The Wayback Machine's crawlers capture the initial HTML response. Single-page applications that render content client-side often archive as a blank page or a loading spinner. SPN2's js_behavior_timeout parameter helps — it gives JavaScript time to execute — but the results are inconsistent. Sites that rely on client-side routing, lazy loading, or dynamic content generation frequently archive incomplete.

No image output. The Wayback Machine doesn't return screenshots. It returns reconstructed web pages. If you need a PNG of how a site looks, you'd have to open the Wayback Machine URL in a headless browser and screenshot that — adding a whole layer of browser automation on top of the Archive's infrastructure. screenshotrun returns the image directly. One call, one image.

Robots.txt compliance blocks many sites. The Wayback Machine respects robots.txt by default. If a site's robots.txt disallows the Internet Archive's crawlers, those pages won't be in the archive at all. Some sites retroactively add robots.txt restrictions that remove previously archived content. For monitoring use cases where you need to capture pages regardless of their robots.txt, only a tool you control can guarantee access.

Using both together

The Wayback Machine and a screenshot API serve different timelines. The Wayback Machine covers the past. A screenshot API covers the present.

A practical combined workflow: use the CDX API to check whether a page was captured last week, last month, last year. If you need the current state of that page — as a screenshot, in a specific format, with content blocking applied — capture it through the API. Store both: the Wayback Machine URL for historical reference, the API-captured image for your application's current needs.

# Check if Wayback Machine has a recent capture
cdx_url="https://web.archive.org/cdx/search/cdx?url=example.com&output=json&limit=-1"
# Returns the most recent capture metadata

# Capture the current state via screenshot API
curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&format=webp&block_ads=true" \
  -H "Authorization: Bearer YOUR_API_KEY"
# Returns a clean WebP screenshot, right now

For legal evidence workflows, this combination is strong. The Wayback Machine provides third-party timestamped archival (credibility through the Internet Archive's reputation). screenshotrun's certified screenshots provide cryptographic proof of current page state (technical evidence that the image hasn't been altered). Different types of evidence, complementary strengths.

Choosing the right approach

If you need to look up how a page appeared in the past — use the Wayback Machine. Nothing else has 28 years of web history in a searchable index. It's free, it's a public good, and the CDX API is powerful for historical research.

If you need to capture how a page looks right now — in a specific format, with rendering controls, content blocking, device emulation, delivered as an image your application can use directly — a screenshot API is built for that job. The Wayback Machine's APIs weren't designed for on-demand screenshot generation, and trying to force them into that role means fighting asynchronous workflows, unpublished rate limits, inconsistent JavaScript rendering.

For a broader look at screenshot tools, the screenshot API comparison covers more options. And if you're building an archiving workflow specifically, the website archiving use case page shows how scheduled API captures can build a private visual archive of any site.

FAQ#