Tinyfishie

Posted on May 19 • Originally published at tinyfish.ai

TinyFish vs Playwright: When to Use Each for Web Automation

#playwright #browserautomation #webscraping #tinyfishvsplaywright

Playwright is running fine. Then you scale to 500 concurrent sessions. Or you add sites with strict automation requirements and reliability drops. Or you realize your team spends more time managing browser infrastructure than building the product.

That's usually when the search starts.

This article is for developers who already use Playwright and want to understand exactly where TinyFish fits — and where it doesn't. Not a takedown. A map.

What Playwright Does (And Why It's Excellent)

Playwright is one of the best browser automation tools available. It controls real Chromium, Firefox, and WebKit browsers with a clean, well-designed API. The ecosystem is mature: thorough documentation, active maintenance from the Microsoft team, and broad community support.

For developers, the appeal is direct. You write the code. You control everything. Intercept requests, manage cookies, record HAR files, take screenshots, assert DOM elements. The degree of control Playwright gives you over browser behavior is genuinely hard to replicate elsewhere.

The critical thing to understand about Playwright: it's a library. It doesn't provide infrastructure. You write the code, you run the infrastructure. That's not a criticism — it's the design. Playwright does exactly what it was built to do.

Where Playwright Hits Limits at Scale

The infrastructure model that makes Playwright flexible at small scale becomes operational overhead as you grow.

Browser server management. Running Playwright at scale means managing fleets of headless Chromium instances — 100–300MB memory per instance. At 50 concurrent sessions, you're making decisions about server scaling, spot instance reliability, and container orchestration.

Proxy configuration. Sites with strict automation requirements often need residential IP rotation. Building proxy rotation into Playwright means integrating a proxy provider, handling session affinity, managing per-request IP logic, and debugging reliability when rotation fails or IP reputations degrade.

Maintenance overhead. When a target site changes its structure or tightens its automation requirements, your scraper breaks. Diagnosing and fixing these failures is real engineering work — work that doesn't ship product, but blocks pipelines.

Reliability degrades with volume. A Playwright script that works at 10 requests/hour can fail at 500/hour — not because the code changed, but because infrastructure factors create failure modes that weren't visible at low volume. Setting up reliable automation on sites with strict requirements takes significant infrastructure work with Playwright alone.

If your targets are static pages on cooperative domains at modest volume, this overhead is manageable. If you're running production pipelines at scale across varied sites, the infrastructure becomes a full-time engineering problem.

For more on where Playwright's reliability degrades by site type, see Scraping Dynamic Websites: When Playwright Is the Right Tool.

Test TinyFish against your hardest URLs — 500 free credits, no credit card

What TinyFish Adds

📸 IMAGE — Architecture comparison showing self-hosted Playwright stack versus TinyFish managed browser infrastructure

Your existing Playwright scripts work. The change is minimal: create a TinyFish browser session, then connect your Playwright code to it.

TinyFish exposes a Browser API that returns a CDP WebSocket endpoint. Since Playwright's connect_over_cdp() method already speaks CDP, connecting to TinyFish instead of launching a local browser requires two lines — create a session, then connect. Everything after that is unchanged:

import os
from playwright.async_api import async_playwright

async with async_playwright() as p:
    # Before: local browser
    # browser = await p.chromium.launch()

    # After: TinyFish managed browser — create a session, then connect
    from tinyfish import TinyFish
    session = TinyFish().browser.sessions.create()
    browser = await p.chromium.connect_over_cdp(session.cdp_url)
    page = await browser.new_page()
    await page.goto("https://example.com")
    content = await page.content()
    await browser.close()

Everything after the connection line — your selectors, page interactions, extraction logic — stays identical.

What changes is the infrastructure layer. Browser servers managed. Residential proxy routing included. Cold starts under 250ms. Browser sessions run with full infrastructure support — proxy routing, session state, and browser configuration are handled server-side. TinyFish achieves up to 85% success rate on sites with strict automation requirements across standard commercial site categories (source: tinyfish.ai).

The biggest difference between TinyFish and Playwright isn't what the browser can do — it's what you no longer have to build. TinyFish removes the infrastructure layer entirely: browser servers, proxy management, reliability handling. Your Playwright code connects unchanged; the operational overhead disappears.

One distinction worth noting: TinyFish also offers a Web Agent layer for goal-based tasks, separate from the Browser API. If your use case is "navigate to X, extract Y, handle the flow autonomously," the Agent endpoint may serve you better than CDP. But for teams with existing Playwright code who want to remove browser infrastructure, the Browser API is the direct path.

Playwright vs TinyFish: Side-by-Side

	Playwright	TinyFish Browser API
Hosting model	Self-hosted (you manage servers)	Cloud-managed
Setup	Library install; infra setup varies	API key, SDK, CLI, or MCP
Maintenance	You own: server ops, proxy config, failure debugging	Managed
Browser cold start	Depends on your hardware	<250ms
Infrastructure reliability	Depends on your implementation	Managed, included
Max concurrent (managed)	Limited by your servers	10 (Starter) / 50 (Pro)
Cost at low volume	Low — library is free	$0.015/credit PAYG
Cost at high volume	Server + proxy + engineering time	$0.012/credit (Pro)
CDP compatible	Native	✅ — existing Playwright scripts work
Full browser control	✅ Complete	✅ via CDP

If Playwright wins a row, it wins. The table is accurate.

One context the table doesn't capture: Playwright's "low" cost at low volume is the library cost. The real cost at scale includes server infrastructure, proxy subscriptions, and the engineering time spent on maintenance. That's what TinyFish replaces — and it's why the economics shift faster than the per-step price suggests.

When to Stick With Playwright

Use Playwright here. It's the right tool.

UI and functional testing. Playwright is purpose-built for testing — test runners, assertions, traces, screenshot comparison. TinyFish is a data extraction and automation platform, not a testing framework.
Simple, stable targets. Working with a small number of cooperative sites whose structure doesn't change? If you're comfortable managing the browser process and the maintenance load is genuinely zero, Playwright is the leaner choice. The threshold isn't about volume — it's about whether infrastructure has become a problem yet.
Local development and prototyping. Building and debugging automation flows is faster with local Playwright — full visibility into browser state, easy debugging, no API latency.
When you need complete control. Custom browser configurations, extension loading, low-level network manipulation — Playwright's architecture gives direct access to things the Browser API abstracts.
Early-stage validation. If you're running quick experiments to test whether a data source is useful before committing to a pipeline, Playwright locally is the fastest path to an answer.

When TinyFish Makes Sense

TinyFish's value is clearest when the infrastructure problem becomes visible. That moment comes sooner than most teams expect.

Production pipelines at scale. When thousands of concurrent sessions make browser infrastructure an ops problem, managed infrastructure is worth the per-step cost.

Teams that don't want to own browser ops. If browser infrastructure isn't a core competency you want to build, outsourcing it is rational — your engineers ship product, not browser fleet maintenance.

Sites with strict automation requirements. Sites that require more reliable infrastructure-level request handling — where JavaScript-layer plugins fail at scale — benefit from TinyFish's infrastructure-level approach. Infrastructure-level request handling is built in at the execution layer, not patched in afterward.

Goal-based multi-step tasks. When your automation requires reasoning about what to do next rather than a fixed selector sequence, the Web Agent layer handles tasks that would require complex conditional Playwright logic.

Mixed complexity URL lists. If your list includes simple pages alongside sites that require more sophisticated handling, routing to TinyFish selectively while keeping Playwright for simple cases is a valid tiered approach.

Can They Work Together?

Yes. This is the most important point in this article: Playwright and TinyFish are not competing tools. They're different layers.

Playwright is the automation library. TinyFish is the infrastructure layer. You can run them in parallel — Playwright for tests and simple sites, TinyFish for production-scale or complex extraction — without any conflict.

The migration is genuinely minimal. Here's a complete working example:

import asyncio
import os
from playwright.async_api import async_playwright

async def scrape(url: str) -> str:
    async with async_playwright() as p:
        # Replace launch() with a TinyFish session — the rest of your code is unchanged
        from tinyfish import TinyFish
        session = TinyFish().browser.sessions.create()
        browser = await p.chromium.connect_over_cdp(session.cdp_url)
        page = await browser.new_page()
        await page.goto(url, wait_until="networkidle")
        content = await page.content()
        await browser.close()
        return content

result = asyncio.run(scrape("https://example.com"))

Your selectors, event handlers, extraction logic — unchanged. The browser runs in TinyFish's managed infrastructure instead of your server.

For session configuration, concurrent session management, and authentication handling, the full documentation is at docs.tinyfish.ai/browser-api.

Read the Browser API docs — connection options, session config, concurrent setup

If you want to try it against your current Playwright scripts, the Getting Started guide walks through first connection in under 10 minutes.

Try TinyFish free — 500 credits, no credit card required

FAQ

Is TinyFish a Playwright alternative or a complement?

Both, depending on what you need. For teams with existing Playwright code, TinyFish's Browser API is a complement — your scripts run unchanged, just on managed infrastructure instead of your server. As a fuller alternative, TinyFish makes sense when you need infrastructure-level reliability at scale or goal-based agent automation. Most teams end up using both: Playwright for testing and simple sites, TinyFish for production-scale or complex extraction.

Can I use my existing Playwright scripts with TinyFish?

Yes. TinyFish's Browser API returns a CDP WebSocket endpoint. Playwright's connect_over_cdp() method connects to any CDP endpoint. The migration is minimal: create a TinyFish browser session, then pass session.cdp_url to playwright.chromium.connect_over_cdp(). Everything after that line — selectors, interactions, extraction logic — runs unchanged.

When does Playwright become impractical at scale?

Common signals: you're spending more engineering time on browser infrastructure than on automation logic; reliability issues appear that aren't in your code; proxy management has become its own project; or target sites with strict requirements need ongoing maintenance as they evolve. If these apply at your current volume, the infrastructure overhead has exceeded the cost of a managed alternative.

How does TinyFish handle sites with strict automation requirements?

TinyFish achieves up to 85% success rate on sites with strict automation requirements across standard commercial site categories (source: tinyfish.ai). Sites that JavaScript-layer plugins can't reliably handle are within TinyFish's standard coverage. For sites outside this coverage, failures are transparent — you won't get silent incorrect results.

What's the cost difference between Playwright and TinyFish at scale?

Playwright's library is free, but at scale the real costs are server infrastructure, proxy subscriptions, and engineering time for maintenance. TinyFish charges $0.012–$0.015 per credit depending on plan, with browser infrastructure, residential proxy, and LLM inference included. Playwright wins at low volume and simple sites; the economics shift toward TinyFish when infrastructure overhead becomes a material cost. The Pro plan ($150/mo) includes 16,500 credits with 50 concurrent agents.

Try TinyFish Free

If the selector maintenance and infrastructure overhead are the bottleneck — not the control — the free tier is the fastest way to compare against your current Playwright setup.

500 free steps, no credit card required.

Start free →

No browser to install, no selectors to write. Describe what you need, get back structured JSON.

DEV Community