Forem: Ohad Badihi

Rendershot vs Urlbox: choosing a screenshot API in 2026

Ohad Badihi — Mon, 04 May 2026 09:41:05 +0000

Picking a screenshot API feels binary until you start integrating, then the edges show: one service has a Python SDK but no async queue, another has webhooks but charges extra for authenticated pages, a third makes you wire up an S3 bucket yourself. This post walks through how Rendershot and Urlbox compare across the dimensions that actually hurt to change later.

Upfront: I build Rendershot, so treat this as a structured comparison with obvious bias, not an impartial review. I've tried to keep every claim about Urlbox pinned to their public docs and pricing page. If anything here drifts out of date, their docs are the source of truth.

The short version

Pick Urlbox if you want an older, battle-tested product with a big feature surface and you're willing to pay a premium for polish. They've been shipping since ~2014.
Pick Rendershot if you want transparent pay-as-you-go pricing, no-code distribution (Zapier, MCP), and AI-based cookie-banner cleanup baked in rather than sold as an add-on.

Both can render screenshots and PDFs, expose a REST API, and return files via URL or inline bytes. Below is where they diverge.

Pricing model

Urlbox prices on renders per month with tiered plans. Overages push you into the next tier. The starter plan (at time of writing) sits in the low double digits; teams with bursty traffic end up paying for headroom they rarely use.

Rendershot prices on credits — one credit per render, buy what you use. Unused credits roll forward. The free tier includes 200 renders per month with no card required, which is enough to prototype an entire Zap end-to-end before committing.

Rough mental model: if your traffic is predictable and high volume, Urlbox tiers work out fine. If your traffic is spiky or you're still figuring out product-market fit, pay-as-you-go avoids the "we hit the limit on a Tuesday" failure mode.

Getting to the first screenshot

Urlbox's signup → API key → first request flow takes a few minutes, plus you authenticate requests by signing URLs with HMAC on your side (their templates help, but it's still code to write).

Rendershot hands you an sk_live_… key and this curl:

curl -X POST https://api.rendershot.io/v1/screenshot \
  -H "X-API-Key: sk_live_..." \
  -d '{"url":"https://example.com","async":true}'

No URL signing, no HMAC — just a header. If you're prototyping, this is a few hundred ms faster per round-trip in "does it work" land. For production, URL signing has security benefits; both approaches are fine, just different.

SDK coverage

Both offer Python and Node.js SDKs. Rendershot additionally has:

MCP server (@rendershot/mcp-server) for Claude, Cursor, Windsurf, and other MCP-compatible AI agents. You can ask an agent to "screenshot this URL" and it'll route through Rendershot.
Zapier app (public beta), with a capture_screenshot action, a capture_pdf action, and a new_render trigger that fires when an async render finishes — with a 24-hour presigned file URL attached, so downstream Gmail / Dropbox / Slack steps can fetch the file without an API key.

Urlbox has a Zapier integration too — worth comparing the action list to see which fits your workflow better.

Authenticated pages

Screenshotting pages behind a login is the feature that most often determines which API sticks. Both services support it.

Urlbox supports cookie / header injection and has a "sessions" concept to reuse authentication across calls.
Rendershot supports authenticated pages via per-request auth params (cookies, headers, storage state), with no separate session storage to manage.

If you need to re-use the same authenticated browser context across many calls in a short window, Urlbox's sessions are easier. If you'd rather send auth context per-request and keep your API stateless, Rendershot matches that shape directly.

AI cleanup

Cookie banners and newsletter popups wreck screenshots taken for marketing/reporting purposes. Both services offer ways to block them — Urlbox has selector-based hiding, Rendershot has an ai_cleanup flag (fast / thorough) that removes them semantically without you writing selectors.

The AI approach is the real differentiator here: it handles sites you haven't seen before, GDPR-compliant sites in different jurisdictions, and redesigns that would break your hard-coded selectors.

Async / queue model

Urlbox returns screenshots synchronously by default and supports polling for large renders.
Rendershot supports both modes: set async: true to get back a job ID immediately, poll /v1/jobs/<id> for status, or subscribe a webhook to be notified when the render finishes. The webhook payload includes a 24-hour presigned file URL — crucial for no-code pipelines where downstream steps can't authenticate.

If your workload is mostly fast single renders, sync is simpler. If you render long-animated pages or bulk-render thousands of URLs, async + webhooks will save you retries and timeouts.

Output storage

Urlbox can return the file directly or upload to your S3 bucket — you bring the storage. Rendershot stores rendered files for 24 hours on Hetzner Object Storage and returns a presigned URL; after 24 hours the file is deleted. You don't need to configure anything.

If compliance requires files stored in your own buckets, Urlbox's BYO-S3 model wins. If you want zero storage configuration and 24h retention is fine, Rendershot's model wins.

When to pick which

Pick Urlbox if:

You want a long-lived product with a broad feature surface.
You need browser-session reuse for authenticated multi-page flows.
You need renders stored in your own S3 bucket for compliance.

Pick Rendershot if:

You value transparent pricing and a generous free tier.
You want a Zapier / MCP / webhook-native integration story.
You want AI-based cookie-banner cleanup rather than selector lists.
You'd rather start with curl in 60 seconds and pay for what you use.

Try Rendershot for free: create an API key at rendershot.io/register. 200 renders / month on the free plan, no card required. If you ship something with it, I'd love to see it — support@rendershot.io.

Headless Chromium at scale: four fixes for a fleet that kept eating RAM

Ohad Badihi — Thu, 30 Apr 2026 07:05:34 +0000

The first time a worker died with an OOM kill in the middle of a render, I assumed it was a bad page — some site with an infinite-scroll loop or a 200MB hero video. The second time it happened, on a different worker rendering a different URL, I started paying attention. The third time, a Tuesday morning, every worker in the fleet went down inside a five-minute window.

Headless Chromium leaks memory. Not in a "oh that's a bug, file an issue" way — in a "this is the operating reality of a 30-million-line C++ browser, and you have to plan around it" way. If you run Playwright or Puppeteer in production for more than a few minutes per request, you will eventually meet this reality. This post is the four things I changed in Rendershot — a screenshot and PDF API I run — that took us from "workers crashing twice a day" to "workers running for weeks without intervention."

None of these are clever. They're the boring discipline of treating a browser like a long-lived process, not a function call.

Setup, in one paragraph

Each Rendershot worker is a Docker container running an ARQ (Redis-backed) job queue. Jobs come off the queue, get rendered with Playwright, and the resulting bytes are uploaded and the file path written back to Postgres. Concurrency is bounded; the worker fleet scales horizontally — no shared state between workers, just one Chromium process each.

That last part was the first fix.

Fix 1 — One browser per worker, not per request

The naive way to run Playwright is the way the docs suggest:

async with async_playwright() as p:
    browser = await p.chromium.launch()
    page = await browser.new_page()
    await page.goto(url)
    await page.screenshot(path="out.png")
    await browser.close()

This is fine for a script. It is catastrophic for a server. Launching Chromium takes 300–600ms on a modern Linux box, allocates ~150MB of resident memory before you've even pointed it at a URL, and forks a small army of helper processes (renderer, GPU, network, utility). Tearing it down repeats most of that work.

If your worker handles 10 renders per second, you are spending more time launching and killing browsers than you are rendering anything. And every leaked file descriptor, zombie subprocess, or partially-released shared memory segment compounds.

The fix is to launch the browser once per worker, on startup, and reuse it for every request:

class WorkerSettings:
    on_startup = startup
    on_shutdown = shutdown
    max_jobs = config.settings.browser_max_pages

async def startup(ctx):
    pool = BrowserPool()
    await pool.start()  # launches one Chromium
    ctx['pool'] = pool

async def shutdown(ctx):
    await ctx['pool'].stop()

Each render now creates a page (cheap, ~5ms), uses it, and closes it. The browser stays alive for the lifetime of the worker. Crash isolation is per-container — if a worker's browser dies, we lose that worker, not the fleet.

Fix 2 — Cap concurrent pages with a semaphore (and match it to your job queue)

A persistent browser will happily let you open 50 tabs. It will also happily eat 8GB of RAM doing it.

You need a hard cap on how many pages render concurrently inside one browser. We use an asyncio.Semaphore:

@dataclasses.dataclass
class BrowserPool:
    max_pages: int = 4
    _semaphore: asyncio.Semaphore | None = None

    async def start(self):
        self._semaphore = asyncio.Semaphore(self.max_pages)
        self._browser = await self._playwright.chromium.launch(args=_CHROMIUM_ARGS)

    async def render_screenshot(self, params):
        async with self._semaphore:
            context, page = await self._new_page(params)
            try:
                await self._navigate(page, params)
                return await page.screenshot(...)
            finally:
                await page.close()
                await context.close()

The non-obvious part: the semaphore alone isn't enough. Your job queue needs to match it. ARQ has a max_jobs setting that controls how many tasks the worker pulls off Redis simultaneously. If max_jobs > max_pages, jobs get pulled, hit the semaphore, and wait — eating queue slots that another worker could be servicing.

class WorkerSettings:
    max_jobs = config.settings.browser_max_pages  # match the semaphore

Both numbers tied to the same setting. No oversubscription. The "right" number for both is a function of how much RAM your container has and how heavy your renders are; we tune ours per environment.

Fix 3 — Restart the browser on a schedule, not on failure

This is the one that took us longest to accept.

Chromium's memory growth is not linear. Most pages cause a small bump that gets mostly reclaimed when the page closes. Some pages — a video, a leaky JavaScript framework, a page with a couple thousand DOM nodes — cause a bump that never gets reclaimed. Over hours and tens of thousands of renders, the resident set creeps. By hour 8 you're at 1.5GB. By hour 24 you're getting OOM-killed.

You can chase the leaks. Profile, diff snapshots, file Chromium bugs. Some of these are real bugs that get fixed. Others are by design — V8's garbage collector is not optimised for long-running, multi-tenant browser fleets.

Or you can preempt: every hour, kill the browser and start a fresh one.

async def maybe_restart(self):
    elapsed = time.monotonic() - self._last_restart
    if elapsed < self.restart_interval:
        return
    async with self._lock:
        if time.monotonic() - self._last_restart < self.restart_interval:
            return
        if self._browser:
            await self._browser.close()
        await self._launch_browser()

We call this from an hourly ARQ cron. The lock prevents two coroutines racing into a restart; the double-check inside the lock handles the case where one already won. A restart costs us about 800ms of latency on whichever request is unlucky enough to land during the swap — we accept it as the price of not paging an engineer.

If you can stomach a slightly more aggressive cadence (every 30 min, every 1000 renders), you can probably get away with a smaller container. We tuned to one hour because it's the sweet spot for our workload.

Fix 4 — A fresh `BrowserContext` per render, and close everything in `finally`

You are not just running renders. You are running other people's renders. Different tenants. Different cookies, different basic auth, different custom headers.

A BrowserContext is Playwright's isolation unit — its own cookies, storage, cache. If two tenants share a context, tenant A's session cookie can leak into tenant B's render. This is bad. You make a fresh context per render and you close it after:

async def _new_page(self, params):
    context_kwargs = {
        'viewport': params.get('viewport') or {'width': 1280, 'height': 720},
    }
    if params.get('headers'):
        context_kwargs['extra_http_headers'] = params['headers']
    if params.get('basic_auth'):
        context_kwargs['http_credentials'] = params['basic_auth']

    context = await self._browser.new_context(**context_kwargs)

    if params.get('cookies'):
        await context.add_cookies(params['cookies'])

    page = await context.new_page()
    return context, page

And on the consumer side — always in a finally block:

context, page = await self._new_page(params)
try:
    await self._navigate(page, params)
    return await asyncio.wait_for(
        page.screenshot(...),
        timeout=self.timeout_seconds,
    )
finally:
    await page.close()
    await context.close()

The asyncio.wait_for is a hard cap on render time — without it, a page can hang on networkidle indefinitely and tie up a semaphore slot. With it, we always close. Without it, a single slow page becomes a fleet outage.

Bonus: Chromium launch flags that actually matter

Most "performance flag" lists you'll find online are cargo-culted. Here's the short list that's been load-bearing for us:

_CHROMIUM_ARGS = [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-dev-shm-usage',  # use /tmp instead of /dev/shm
    '--disable-gpu',
    '--disable-extensions',
    '--disable-background-networking',
    '--mute-audio',
    '--hide-scrollbars',
]

The most important one is --disable-dev-shm-usage. By default Chromium uses /dev/shm for shared memory between processes; in a container, /dev/shm is typically tiny (64MB), and a busy renderer will OOM the moment it tries to allocate a large pixmap. Routing it to /tmp (which is just regular disk-backed memory) trades a small amount of latency for not crashing.

--no-sandbox and --disable-setuid-sandbox are required if you're running as a non-root user in Docker without the right capabilities. They're a downgrade in defense-in-depth — if you're rendering URLs supplied by your own tenants you should weigh whether to instead grant the container the right caps. For our threat model (tenants render their own URLs, not ours), the tradeoff is acceptable.

What I'd do differently

If I were starting again:

Cap viewport size aggressively at the schema layer, not in the renderer. We started lenient ("let people render at 4K!") and walked it back when one tenant's 8K full-page screenshot used 2GB of RSS for one render.
Track per-render memory, not just per-worker. A page that allocates 800MB before crashing should be killed and the tenant should see a clear error, not a generic 504. We added this later; should have been from day one.
Treat browser restarts as a SLO, not a coincidence. Once we started measuring "% of requests that landed during a restart," we could tune the cadence with data instead of hunches.

Closing

There's nothing magical here. One browser per worker, semaphore-capped concurrency, scheduled restarts, fresh contexts. The discipline is in actually doing all four; skipping any one of them eventually crashes a worker.

If you're running a screenshot API, a PDF generator, an HTML-to-image pipeline, or any other long-running headless-browser workload, the same pattern applies. If you'd rather not run any of this yourself, Rendershot is the API that comes out of the patterns above — free tier of 200 renders/month, no card required.

If you're sizing up screenshot/PDF APIs, I also wrote a structured comparison: Rendershot vs Urlbox: choosing a screenshot API in 2026