screenshotrun vs Screenshotlayer: Honest Comparison for Developers

Why do developers start searching for a screenshotlayer alternative? Usually one of three things happened: a screenshot came back half-rendered, a cookie banner covered the entire viewport, or HTTPS was locked behind a paid plan. Screenshotlayer has been around since roughly 2015 as part of the apilayer family (the same Vienna-based company behind currencylayer, mediastack, and ipstack), and for years it was one of the few screenshot APIs offering a free tier. Plenty of developers wired it into their projects early. But the web moved on — CSS Grid, client-side JavaScript frameworks, lazy loading, SPAs that render entirely in the browser — and the rendering engine behind Screenshotlayer hasn't kept pace.

This page compares screenshotrun and Screenshotlayer across rendering, features, pricing, and developer experience. Full disclosure: I built screenshotrun, so I'm biased. Both APIs get honest strengths and honest weaknesses below.

Do you actually need a different API?

Before comparing anything, it's worth asking whether Screenshotlayer's current problems are solvable within the tool. If screenshots are blank or half-loaded, try the delay parameter: set it to 3 or 5 seconds to give JavaScript time to execute. If cookie banners are blocking content, there's no built-in fix (Screenshotlayer has no content blocking), but an external CSS file via css_url can hide elements with display: none. That workaround requires hosting a CSS file somewhere, but it works for simple cases.

If the issue is HTTPS support on the free plan, or PDF generation, or rendering modern React/Vue apps correctly, those aren't configuration problems. They're platform limitations. That's when a different apilayer screenshot API alternative starts making sense.

screenshotrun vs Screenshotlayer: feature comparison

The table tells the story clearly. Screenshotlayer has a handful of features screenshotrun doesn't: S3/FTP export, CDN-hosted screenshots, and a placeholder image while rendering. Those are genuinely useful for certain architectures. But the list of what Screenshotlayer lacks is long: no selector-based waiting, no content blocking, no dark mode, no device emulation presets, no PDF output, no HTML input, no custom headers, no webhook delivery, no AI agent support. And the features it does offer are often gated behind paid plans.

The rendering problem

This is the core issue. A screenshot API is only as good as its rendering engine, and Screenshotlayer's engine struggles with the modern web.

Try capturing a React dashboard, something like Grafana or a Notion page. Pages like these load data asynchronously after the initial HTML arrives. The page shell appears first, then JavaScript fetches data from APIs and populates the DOM. Screenshotlayer's only timing control is a fixed delay parameter measured in seconds. Set it too low, and the screenshot captures an empty shell. Set it too high, and response times suffer. There's no way to say "wait until this specific element appears" the way wait-for-selector does.

Modern CSS is another pain point. Flexbox-heavy layouts, CSS Grid, container queries, backdrop-filter. These render correctly in Chromium-based engines but may break in older proprietary renderers. If a site looks fine in Chrome but wrong in the Screenshotlayer screenshot, the rendering engine is almost certainly the cause.

screenshotrun uses Playwright with headless Chromium, the same engine that powers Chrome, Edge, and Brave. The screenshots match what users see in their browsers because the rendering engine is the same one.

Screenshotlayer pricing vs screenshotrun

Screenshotlayer pricing follows a volume-based model with four tiers. The per-screenshot economics look competitive at first glance. At $0.002 per screenshot on the Basic plan, the raw cost is genuinely low. But the feature gating changes the real cost.

At raw screenshot volume, Screenshotlayer pricing beats screenshotrun from 10,000 screenshots onward. That's a real advantage for teams that only need basic URL-to-image conversion at scale. The $19.99/month for 10,000 screenshots is hard to match.

But pricing alone doesn't tell the full story. The Screenshotlayer free plan restricts HTTPS, retina, and WebP quality settings to paid tiers. In 2026, most websites serve over HTTPS. A free tier that can't capture HTTPS sites is effectively a demo, not a usable plan. screenshotrun includes HTTPS, retina, and every feature on the free tier: 200 screenshots per month with no restrictions.

What Screenshotlayer does well

Fair is fair. Screenshotlayer has real strengths in specific areas.

The most notable one is built-in CDN hosting. Screenshots are stored and served from Screenshotlayer's infrastructure, so you get a URL back that you can embed directly. No need to download the image, store it in S3, and serve it yourself. For teams building link preview systems or directories that display thousands of thumbnails, this eliminates an entire layer of infrastructure. screenshotrun doesn't host screenshots — you get the image binary in the response and manage storage yourself.

Screenshotlayer also supports S3 and FTP export on paid plans, shipping screenshots directly to your storage without routing through your application server. For high-volume batch processing, that reduces bandwidth and simplifies the pipeline. There's also a placeholder image feature that displays a fallback while the real screenshot renders, which is useful for client-facing applications where an empty space looks worse than a temporary image.

And then there's longevity. Screenshotlayer has been operational since approximately 2015. The apilayer ecosystem serves millions of API calls across its products. That kind of track record matters for enterprise teams evaluating vendor risk.

The JavaScript and SPA problem

Single-page applications built with React, Vue, Angular, or Svelte render content in the browser. The server sends a mostly-empty HTML shell, and JavaScript builds the actual page after it loads. A screenshot API that captures the page before JavaScript finishes gets a blank or half-rendered result.

Screenshotlayer's approach is a fixed delay: wait N seconds, then capture. That works sometimes. It fails when the page load time varies. Maybe the API response takes 500 milliseconds on one request and 4 seconds on the next. A fixed delay either wastes time or misses content.

screenshotrun solves this with wait-for-selector. Instead of guessing how many seconds to wait, you tell the API "capture after this CSS selector appears in the DOM." When the dashboard chart renders, the data table populates, or the login form shows up, that's when the screenshot fires. No guessing, no wasted time.

There's also click_selector for pages that require interaction before showing content (expanding dropdowns, dismissing modals, accepting terms), and scroll_to for triggering lazy-loaded images lower on the page. Screenshotlayer has no equivalent for any of these.

Content blocking: cookie banners, ads, and chat widgets

Every screenshot API user eventually runs into the same problem: the screenshot looks great except for the massive cookie consent popup covering half the page. Or the chat widget floating in the corner. Or the interstitial ad.

Screenshotlayer has no built-in content blocking. The only workaround is injecting an external CSS file via the css_url parameter to hide specific elements. That requires hosting a CSS file, knowing the exact selectors for each site's popups, and maintaining that file as sites change their markup. It works, but it's brittle.

screenshotrun handles this with dedicated parameters: block_cookies removes consent banners automatically, block_ads strips ad units, block_chats hides live chat widgets, and hide_selectors removes any arbitrary elements by CSS selector. One API call, clean screenshots.

API comparison: a simple screenshot request

Here's the same task with both APIs: capturing a full-page screenshot of a URL.

Screenshotlayer:

curl "http://api.screenshotlayer.com/api/capture?access_key=YOUR_KEY&url=https://example.com&fullpage=1&viewport=1440x900&format=png"

Note the HTTP endpoint. HTTPS API access requires a paid plan.

screenshotrun:

curl -X GET "https://screenshotrun.com/api/v1/screenshots/capture?url=https://example.com&full_page=true&width=1440&height=800&format=png" \
  -H "Authorization: Bearer YOUR_KEY" \
  --output screenshot.png

Both return a PNG image. The differences show up when you need more: adding &block_cookies=true&wait_for_selector=.dashboard-chart&dark_mode=true to screenshotrun gets you a clean, dark-mode, properly-loaded screenshot in one request. Screenshotlayer has no equivalent parameters for any of those.

When Screenshotlayer is the better choice

Screenshotlayer makes sense for teams that need high-volume, simple URL-to-image conversion at the lowest per-screenshot cost. At $19.99 for 10,000 screenshots, it undercuts most competitors on pure volume pricing. The built-in CDN hosting eliminates storage infrastructure entirely, which is a real advantage for teams that don't want to manage S3 buckets or image serving. And the S3/FTP export pipeline works well for batch processing at enterprise scale.

If the target sites are simple (static HTML, server-rendered pages, marketing sites without heavy JavaScript), Screenshotlayer's rendering limitations won't matter. The screenshots will look fine.

When screenshotrun is the better screenshotlayer alternative

screenshotrun fits better when the requirements go beyond basic captures. Modern web apps that rely on client-side rendering need selector-based waiting, not fixed delays. Pages cluttered with cookie banners and chat widgets need automatic content blocking. Workflows that require PDF output alongside image screenshots need a single API that handles both. Screenshotlayer forces you to use a separate product (pdflayer) for PDFs.

Dark mode captures, device emulation presets, inline CSS/JS injection, custom headers, stealth mode for bot-protected sites, and a first-party MCP server for AI agents. None of these exist in Screenshotlayer. For teams building anything beyond a simple thumbnail generator, the feature gap is the deciding factor, not the price difference.

The free tier difference matters too. Screenshotlayer gives you 100 screenshots per month with no HTTPS support. screenshotrun gives 200 per month with every feature included. For integration testing and prototyping, that's the difference between a usable evaluation and a frustrating demo.

Making the right choice

Screenshotlayer and screenshotrun represent two different eras of screenshot APIs. Screenshotlayer was built when most sites were server-rendered and a simple delay was enough to capture them. screenshotrun was built for the current web — SPAs, dynamic content, cookie consent laws, dark mode preferences, and AI agent workflows.

The honest test is simple: take your five most important target URLs and run them through both APIs. If Screenshotlayer renders them correctly and you don't need PDF output, content blocking, or selector-based waiting, the lower per-screenshot cost is a valid reason to stay. If the screenshots come back broken, half-loaded, or covered in popups, the rendering engine is the bottleneck and no amount of delay tuning will fix it.

For broader context on choosing a screenshot API, the best screenshot API comparison covers eight providers head to head. The free screenshot API roundup compares free tiers across the market. If you're coming from a self-hosted setup, the Puppeteer vs screenshot API comparison explains the tradeoffs. And for teams evaluating other specific alternatives, I've written similar comparisons against ScreenshotOne, Urlbox, and ApiFlash.

I've tried to be fair here despite the obvious bias. The data in the tables is verifiable on both pricing pages. Test both, pick the one that matches what you actually need.