Screenshot Machine Alternative: Modern Screenshot API for Developers

Screenshot Machine has been capturing websites since around 2012. The API works, the pricing is cheap, the basic thumbnail generation still does the job. But the web has changed considerably since Screenshot Machine's core architecture was built. Single-page applications, lazy-loaded images, cookie consent walls, bot detection — none of these existed when the service launched. Developers searching for a screenshot machine alternative usually hit one of these modern rendering problems first. I'm the founder of screenshotrun — keep that bias in mind while reading. Everything technical below is checkable against Screenshot Machine's public API docs and screenshotrun's documentation.

This comparison covers where Screenshot Machine still works fine, where its age shows, how the APIs differ technically, what to consider when switching.

Two generations of screenshot API

Screenshot Machine was built in the early 2010s, when most websites were server-rendered HTML with jQuery sprinkled on top. Its API reflects that era: GET request with query parameters, API key passed in the URL, MD5 hash for request signing, image returned directly. Simple, effective for its time.

The problem is that web pages got dramatically more complex. Client-side rendering with React, Vue, Angular. Lazy loading via Intersection Observer. Cookie consent banners required by GDPR. Aggressive bot detection by Cloudflare, Akamai, PerimeterX. Screenshot Machine's architecture predates all of this — and the API hasn't added the controls developers need to handle these cases.

screenshotrun was built after these problems were already widespread. The API includes content blocking, stealth mode, device emulation, dark mode, geolocation — parameters that exist because the modern web demands them. Not because we're smarter. Because we had the benefit of building later.

API design differences

The architectural gap shows up immediately when you compare API calls.

Screenshot Machine authenticates via API key in the query string, with an optional MD5 hash for request verification:

# Screenshot Machine — key in URL, MD5 hash signing
curl "https://api.screenshotmachine.com/?key=YOUR_KEY&url=https://example.com&dimension=1280xfull&format=png&delay=2000&hash=MD5_HASH"

API keys in URLs show up in server logs, browser history, CDN caches, referer headers. Every proxy between your server and theirs can read the key in plaintext. MD5 has been cryptographically broken since 2004 — collision attacks are trivial. Modern APIs use Bearer tokens in headers specifically to avoid these exposure vectors.

# screenshotrun — Bearer token in header, not in URL
curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&full_page=true&format=webp&block_ads=true" \
  -H "Authorization: Bearer YOUR_API_KEY"

Beyond authentication, the parameter design tells you what each API was built to handle. Screenshot Machine gives you dimension, format, delay, zoom, device. That covered most needs in 2012. screenshotrun adds block_cookies, block_ads, block_chats, stealth, dark_mode, retina, geolocation, css, js, webhook_url — because those are the parameters developers actually need when capturing the modern web.

Side-by-side comparison

Where Screenshot Machine still works

For basic thumbnail generation of simple, public websites, Screenshot Machine does the job at a low price point. The API is straightforward — one GET request, image back. If your use case is generating preview thumbnails for a link directory or internal dashboard, and the sites you capture are mostly static HTML pages without aggressive bot protection, Screenshot Machine handles that reliably.

The 14-day cache system is actually well-designed for thumbnail use cases. Repeated requests for the same URL return the cached version without counting against your quota. If you display the same set of thumbnails to multiple users, that caching saves real money. screenshotrun has a cache_ttl parameter too, but Screenshot Machine's approach of defaulting to 14 days makes sense for the use case it was built for.

The crop parameter is another feature worth noting. You specify an x/y offset plus width/height in pixels, and the API returns just that rectangle. Useful if you only need a specific section of a page — a hero image, a pricing table, a header. screenshotrun handles the same through CSS selectors or injection, which is more flexible but requires knowing the DOM structure.

At €9/month for 2,500 screenshots with overage at €0.004 each, the pricing is competitive for low-volume use cases. The free tier gives you 100 monthly captures to test with — though free-tier screenshots include a watermark, which limits real production use.

Where Screenshot Machine shows its age

The limitations cluster around everything that changed in web development over the past decade.

No modern image formats. Screenshot Machine outputs JPG, PNG, GIF — nothing else. No WebP, no AVIF. WebP produces files 25-35% smaller than PNG at equivalent quality. AVIF cuts that further. If you serve screenshots to end users in a web application, older formats mean slower page loads and higher bandwidth costs. GIF as a screenshot format is particularly dated — it was included because GIF thumbnails were common in 2012 directories.

No content blocking. Cookie consent banners, ad overlays, chat widgets — Screenshot Machine captures them all. The hide parameter accepts CSS selectors, so you could manually hide specific elements. But that requires knowing the exact selectors for every site's cookie banner, which changes constantly. screenshotrun's block_cookies uses maintained filter lists (similar to how ad blockers work) that adapt as sites change their consent implementations.

No stealth mode. Sites behind Cloudflare or Akamai WAFs frequently block Screenshot Machine's requests. A third-party benchmark by Scrapfly measured a 69% failure rate on bot-protected sites. The service has no mechanism to make its headless browser appear as a regular desktop visitor. For monitoring or capturing bot-protected sites, this is a hard blocker — not something you can work around with parameters.

No retina output. Screenshot Machine has a zoom parameter (10-400%), but zoom and device pixel ratio are different things. Zooming scales the page layout; retina rendering doubles the pixel density while keeping the layout at 1x scale. If you need sharp screenshots for high-DPI displays, zoom at 200% gives you larger images with different layout, not crisper ones.

Lazy loading problems on full-page captures. Screenshot Machine supports full-page screenshots via dimension=1280xfull. But it captures after the initial page load plus a configurable delay (up to 10 seconds). Images that load via Intersection Observer — triggered only when the user scrolls to them — never appear in the screenshot because nothing scrolls the page. screenshotrun's full-page mode automatically scrolls through the entire document to trigger lazy-loaded content before capturing.

No webhook delivery. The API returns the image synchronously. For high-volume or slow-loading pages, that means your server waits for every capture to finish. Webhooks let you fire the request and receive the result asynchronously — your server doesn't block, the image arrives when it's ready.

Authentication and security

This deserves its own section because the gap is significant for production applications.

Screenshot Machine passes the API key as a query parameter: ?key=YOUR_KEY. If you call the API from a frontend application, that key is visible in the network tab of every user's browser. Even from a backend, the key appears in server access logs, load balancer logs, CDN caches, any monitoring tool that captures request URLs.

The optional MD5 hash adds a layer of request verification — you compute md5(url + secret_phrase) and include it in the request. This prevents someone from reusing your key with different URLs. But MD5 has been broken since 2004. Collision attacks are practical. The hash provides protection against casual abuse, not against determined attackers.

screenshotrun uses Bearer token authentication in the HTTP Authorization header. Headers are encrypted in transit via TLS, not logged by default in most infrastructure, never cached by CDNs or proxies. The API key never appears in the URL. Any organization with SOC 2 or PCI requirements expects header-based auth as a baseline — not an optional upgrade.

Pricing comparison

At the lowest tier, the pricing is nearly identical. The gap opens at mid-volume: screenshotrun's $29 plan includes 10,000 screenshots with every feature. Screenshot Machine's Pro plan costs €59 (~$64) for 20,000 screenshots but without content blocking, stealth mode, modern formats, retina output. Whether the extra features justify the per-screenshot price difference depends on your capture requirements. If you need clean screenshots of bot-protected sites in WebP format, Screenshot Machine can't do it at any price.

Migration from Screenshot Machine

If you're switching, the API mapping is mostly straightforward:

# Screenshot Machine parameters → screenshotrun equivalents
# key=YOUR_KEY              → Authorization: Bearer YOUR_API_KEY (header)
# url=https://example.com   → url=https://example.com (same)
# dimension=1280x800        → width=1280&height=800
# dimension=1280xfull       → width=1280&full_page=true
# format=png                → format=png (same, plus webp/avif/tiff/pdf)
# delay=2000                → delay=2000 (same, milliseconds)
# device=phone              → device=mobile
# click=.button             → click_selector=.button
# hide=.banner,.popup       → hide_selectors[]=.banner&hide_selectors[]=.popup
# selector=.main            → selector=.main (same)
# zoom=200                  → retina=true (for 2x) or css injection for zoom
# cacheLimit=0              → cache_ttl=0 (force fresh capture)

The biggest change is authentication. Move the API key from the URL to the Authorization header. If your code constructs the Screenshot Machine URL with string concatenation, you'll need to restructure the request to use HTTP headers instead.

Parameters that exist in screenshotrun but have no Screenshot Machine equivalent — block_cookies, block_ads, stealth, dark_mode, geolocation, webhook_url, certified — are all optional. Your existing captures work without them. Add them incrementally based on what your use case needs.

When Screenshot Machine is good enough

If all four of these apply, Screenshot Machine might be the right call:

• You capture mostly static, public websites without bot protection
• You don't need WebP, AVIF, or PDF output
• Cookie banners and ad overlays in your screenshots are acceptable
• Your captures don't include sites behind Cloudflare or similar WAFs

That describes a shrinking set of use cases. Five years ago it covered most of the web. Today, over 20% of websites sit behind Cloudflare. Cookie consent banners appear on virtually every European site. But if your specific capture targets are simple public pages, Screenshot Machine's low cost and straightforward API do the job without complexity you don't need.

When you need something more

The moment any of these enter the picture, Screenshot Machine can't help:

• Bot-protected sites that block automated access
• Clean captures without cookie banners or ad overlays
• Modern image formats for web performance (WebP, AVIF)
• Retina screenshots for high-DPI displays
• Dark mode captures
• Geolocation-specific rendering
• PDF generation from the same endpoint
• Webhook delivery for async workflows
• Certified screenshots for legal evidence

These aren't edge features. They're what the modern web requires from a screenshot API. The gap between Screenshot Machine's 2012 architecture and current web complexity keeps widening — every new framework that renders client-side, every site that adds Cloudflare, every cookie regulation that creates consent banners, pushes more captures beyond what Screenshot Machine can handle cleanly.

If you want to compare more providers, the screenshot API comparison page covers the full field. And if you're evaluating APIs specifically for thumbnail generation, the website thumbnails use case page shows how different rendering options affect thumbnail quality.

FAQ#