Browshot Alternative

Looking for a browshot alternative? Typical scenario: you've set up Browshot, everything works, but every new API call starts with the question "which instance_id do I need?" — a numeric code that tells the API which browser and server to use (for example, 12 = Chrome on a shared US server). And ends with counting credits. A desktop screenshot costs 1 credit, mobile costs 2. No WebP, no webhooks, no wait-for-selector, no dark mode.

ScreenshotRun removes that complexity: a single device parameter instead of numeric IDs, six output formats including WebP and AVIF, webhook delivery, and a free tier of 200 captures with no credit card. Browshot is still stronger in multi-browser rendering (Firefox, Safari) and multi-step automation — and I'll honestly show that below.

What follows is a detailed comparison: architecture, pricing, both APIs' code side by side, a feature table, and specific gaps in each service.

Fifteen years of screenshots, one unusual design choice

Browshot launched back in 2011. At the time, offering multiple browser engines was a real differentiator. Chrome, Firefox, iPhone Safari, Android Chrome: each got a numeric ID — essentially a code number that tells the API which browser to use — in Browshot's instance catalogue. Want Chrome on a US server? That's instance 12. Firefox on a European server? Different ID. Mobile Safari? Another one entirely. You look up the catalogue at /api/v1/instance/list, find the right number, and pass it as instance_id in every API request.

That made sense in 2011 when browsers rendered pages differently enough that the choice mattered. In 2026, Chrome handles 90%+ of rendering use cases, and most developers just want a screenshot of what their users see. The instance system adds a lookup step before you can make your first API call, and it introduces a coupling between your code and Browshot's internal infrastructure numbering.

ScreenshotRun skips the catalogue entirely. You pass device: "desktop" or device: "mobile" or device: "tablet" and the API handles browser selection internally. No numeric IDs to memorize, no catalogue endpoint to query first. You can also set custom viewport dimensions directly with width and height if you need something specific.

What happens when you pay per credit

Browshot uses a credit system where one dollar buys 10 credits. Desktop screenshots cost 1 credit each, mobile screenshots cost 2. That mobile penalty adds up quickly if you're capturing responsive designs across breakpoints.

Pricing scales non-linearly: $1 gets you 10 credits, $10 gets 1,000, $100 gets 20,000, and $1,000 gets 300,000. The per-screenshot cost drops as you buy in bulk, but predicting your monthly spend requires knowing your exact desktop-to-mobile ratio ahead of time. Mix in a few hundred mobile captures and the math gets uncomfortable. I ran a rough calculation for a pipeline that captures 3,000 URLs monthly (60% desktop, 40% mobile): 1,800 desktop credits plus 2,400 mobile credits equals 4,200 credits total, which lands in the $10-25 range depending on volume tier. Not expensive, but the mental overhead of tracking credit consumption is real.

ScreenshotRun charges a flat monthly rate. $9 for 3,000 screenshots. $29 for 10,000. $99 for 50,000. Desktop, mobile, tablet, PDF, WebP, AVIF: all count as one screenshot. No multipliers, no credit math to think about. The free plan gives you 200 per month with no credit card and no feature restrictions.

For teams that run consistent volumes, flat pricing removes a category of operational thinking. You know the bill before the month starts. And you never have to explain to a product manager why this month's screenshot bill was 40% higher because someone added a batch of mobile captures to the pipeline.

Two API calls side by side

Browshot authenticates via API key in the URL query string. ScreenshotRun uses a Bearer token in the Authorization header (a standard way to send your API key inside the request headers instead of the URL), which keeps your key out of server logs and browser history. Credentials in URLs have a habit of leaking into places you don't expect: proxy logs, Referer headers, shared terminal scrollback, even Slack pastes when someone shares a curl command with a coworker.

Browshot request (you need to know the instance_id beforehand):

curl "https://api.browshot.com/api/v1/screenshot/create\
?url=https://example.com\
&instance_id=12\
&size=page\
&format=png\
&key=YOUR_API_KEY"

ScreenshotRun request:

curl "https://api.screenshotrun.com/v1/screenshots/capture\
?url=https://example.com\
&full_page=true\
&format=png" \
  -H "Authorization: Bearer YOUR_API_KEY"

Beyond authentication, the workflow itself differs. Browshot returns a job ID. You poll the status endpoint (meaning your code keeps asking "is it done yet?" in a loop) until the screenshot is finished, then download the image from a separate URL. That's two to three round trips minimum. ScreenshotRun returns the screenshot directly in the response, or sends it to a webhook URL if you prefer async delivery. One round trip for sync, zero polling for async.

For anyone building production pipelines, that polling step matters more than it seems. You need retry logic (try again if it fails), gradually increasing wait times between retries, and timeout handling, and a way to detect when a job silently stalls. Webhook delivery pushes all of that to the API provider. Your code just listens for the POST.

Feature comparison: what each API actually ships

Where Browshot still earns its keep

Credit where it's due. Browshot does a handful of things that ScreenshotRun doesn't match today.

Multi-browser support is the big one. Browshot can render pages in Firefox, not just Chromium. If you need to verify how a page looks across browser engines, or if you're doing cross-browser visual QA and need Firefox-specific rendering, Browshot gives you that option. ScreenshotRun runs Chromium only. For 95% of screenshot use cases that's fine (Chromium and Firefox render nearly identically on most sites), but cross-browser visual testing is one area where the instance system actually pays off.

Automation steps go further than a single click. Browshot supports multi-step workflows: click a button, wait, scroll, click another element, navigate to a second page, then capture. If your screenshot requires a four-step login flow before reaching the target page, Browshot handles that sequence natively. I haven't built multi-step workflows into ScreenshotRun yet. You get click_selector, scroll_to, and JS injection, which covers most single-interaction scenarios, but chained page navigation isn't there.

SDK breadth is wider too. Browshot ships PHP, Python, Node.js, Ruby, and Perl libraries. Perl is niche in 2026, but Ruby matters if your stack runs on Rails and you prefer a native gem over raw HTTP calls. ScreenshotRun has Node.js, Python, PHP, and cURL examples, with more languages coming.

Browshot also supports up to 5,000px screen width, and full-page captures up to 15,000px tall. Those are generous limits for edge cases like ultra-wide dashboard screenshots or extremely long single-page sites. Most APIs cap well below 15,000px on full-page, so if you're capturing something like a Notion document that runs 10,000+ pixels, Browshot handles it without truncation.

One more thing: Browshot lets you use a Brave browser instance for ad blocking, which is a creative approach. Instead of maintaining filter lists on the server side, they offload the blocking to a browser that does it natively. Different philosophy from ScreenshotRun's toggle-based block_ads parameter, but it works.

Six gaps Browshot hasn't closed

Modern image formats are the most visible gap. WebP saves 25-35% file size over PNG at equivalent quality. AVIF pushes savings even further. Browshot offers PNG, JPEG, and PDF only. If you're serving screenshots to end users or storing thousands of captures monthly, format choice directly affects bandwidth costs and storage bills. A full-page screenshot of a typical e-commerce product page comes in around 2-4 MB as PNG. The same capture in WebP drops to 1.5-2.5 MB. Multiply that across 10,000 screenshots and the difference is real. ScreenshotRun supports PNG, JPEG, WebP, AVIF, TIFF, and PDF.

No HTML or Markdown input means Browshot captures live URLs only. Need to turn an email template, an invoice, or a Markdown document into an image? You'd have to host it somewhere first, then pass the URL to Browshot. ScreenshotRun accepts raw HTML and Markdown directly in the API request body.

Dark mode capture doesn't exist in Browshot's API. You'd need to inject JavaScript to toggle prefers-color-scheme: dark via Browshot's JS execution feature, which means writing and maintaining that injection code yourself. ScreenshotRun has a one-parameter dark_mode=true toggle.

Webhook delivery is missing entirely. Browshot uses a poll-based workflow: submit a screenshot job, check the status endpoint repeatedly until it finishes, then download. For high-volume pipelines doing hundreds of captures per hour, polling creates unnecessary HTTP traffic and forces you to build a status-checking loop. ScreenshotRun pushes the finished screenshot to your webhook URL when it's ready.

Wait-for-selector doesn't exist on Browshot's side. You get delay (a fixed pause from 0 to 60 seconds), but no way to say "capture when this specific element appears in the DOM." Fixed delays waste time on fast pages and miss content on slow ones. A page that loads in 800ms still waits the full delay. A page where React hydration takes 8 seconds might not finish in time. ScreenshotRun's wait_for_selector watches for the element and captures the moment it renders (we use a MutationObserver internally — a browser API that fires the moment something changes on the page — rather than polling the DOM, so it catches elements that appear between check intervals).

No-code integrations are absent from Browshot. No Zapier, no Make, no n8n. If your team includes non-developers who need automated screenshots (marketers pulling competitor pages weekly, designers capturing design references), they'd need to write code or ask someone who can. ScreenshotRun connects to Zapier, Make, n8n, and Google Sheets without touching an API directly.

And there's no MCP server on Browshot's side. If you're using Claude, Cursor, or another AI tool that supports MCP, ScreenshotRun plugs in directly. You can ask your AI assistant to capture a screenshot and it calls the API through the MCP protocol. Browshot predates the MCP standard, and there's no sign they're building toward it.

The instance_id problem in practice

Every Browshot API call requires an instance_id parameter. Before your first screenshot, you call /api/v1/instance/list, parse the JSON response (it returns dozens of instances), find the one matching your desired browser and server location, extract the numeric ID, and hardcode it into your integration.

The risk here: if Browshot changes or removes an instance number, your code stops working and you won't get an obvious error — just a failed capture or the wrong browser. With a parameter like device: "mobile" that problem doesn't exist, because the API figures out the browser internally and your code never touches infrastructure IDs.

On Browshot, capturing the same URL on desktop and mobile requires two different instance IDs and costs different credit amounts (1 credit desktop, 2 credits mobile). On ScreenshotRun, you change one parameter value. The cost is identical either way.

There's also a subtlety around free instances. Browshot's default free instance is #12, a Chrome browser on their shared infrastructure. Other instances (faster servers, dedicated resources, specific geolocations) come at higher credit costs. The instance system doubles as a performance tier — free instance #12 sits on shared infrastructure, while faster servers and dedicated resources cost more credits. Not immediately obvious from the docs.

Picking the right browshot alternative

Browshot fits if you need multi-browser rendering (Firefox captures specifically), multi-step automation workflows that navigate through login sequences, or if your team has a stable integration and the credit costs are predictable at your volume. Fifteen years of operation counts for something, and the SDK coverage across five languages is wider than most screenshot APIs offer.

As a browshot alternative, ScreenshotRun fits if you want flat monthly pricing with no per-format or per-device penalties, modern image formats like WebP and AVIF, HTML/Markdown input without hosting files first, webhook delivery instead of polling, or MCP integration for AI-powered tools. Every feature ships on every plan, including the free tier of 200 screenshots per month.

If Browshot's automation steps are the main thing keeping you there, check whether ScreenshotRun's combination of click_selector, wait_for_selector, scroll_to, and JS injection covers your workflow. For single-interaction captures, it will. For multi-page login sequences, Browshot still has the edge. That's a gap I'm aware of and haven't closed yet.

Start with ScreenshotRun's free tier on the URLs that matter most to you. If the captures look right and the parameters cover your workflow, the migration path is straightforward: swap the endpoint, drop the instance_id, and add the Authorization header.

For more screenshot API comparisons, see best screenshot API, Puppeteer vs screenshot API, Playwright vs screenshot API, ScreenshotRun vs Urlbox, and ScreenshotRun vs Screenshotone.