Lightpanda vs Browserless: Cutting the Cost of Headless Rendering (2026)

On list prices read 2026-07-27, a million rendered pages lands somewhere near $1,500 in Browserless units and near $19 in Lightpanda browser hours. A gap that wide is a hint that the two products are not doing the same work, and they aren't. Rendering is where a crawl budget goes: fetching and parsing HTML costs almost nothing, and running a browser until a JavaScript-built page becomes a queryable DOM costs almost everything.

Lightpanda and Browserless come at that line item from opposite ends. Lightpanda is a headless browser engine written from scratch in Zig that deliberately skips most of what a real browser does. Browserless runs actual Chrome, Firefox and WebKit in a managed pool and optimizes around the browser instead of replacing it. Both sit in the browser infrastructure category, and a team rendering at volume will look at both.

The deciding question is narrower than it first looks: what fraction of your targets can a non-Chromium engine render correctly? Everything else follows from that number.

Head to head

The engine question

Lightpanda's GitHub README is unusually direct about what it is. The project states: "Lightpanda is in Beta and currently a work in progress. Stability and coverage are improving and many websites now work. You may still encounter errors or crashes." It also says, of Web API coverage, "There are hundreds of Web APIs. Developing a browser (even just for headless mode) is a huge task. Coverage will increase over time."

Read the implemented list and the shape of the trade becomes clear. HTTP loading through libcurl, HTML5 parsing, a DOM tree, JavaScript through V8, XHR and fetch, DOM manipulation, clicking, form input, cookies, custom headers, proxy support, network interception, robots.txt handling. That is a complete enough stack to run a modern single-page app to the point where its content exists in the DOM.

What is not on the list is layout and paint. Lightpanda builds no render tree, so there are no screenshots, no PDFs, no element bounding boxes, no CSS-driven visibility test, no canvas and no WebGL. If your extraction logic reads text out of the DOM, none of that matters. If it clicks the third button in a visually sorted grid, or waits for an element to become visible, or captures evidence images for a compliance archive, the engine cannot help you.

There is a second, less obvious failure mode. A site that calls a Web API Lightpanda has not implemented yet does not degrade gracefully; the script throws and the page ends up half built. You will not find these by reasoning about it. You find them by running your target list and diffing the output against a real browser. That test is cheap and it is the only honest way to size the risk.

Browserless has no equivalent question because it runs the real thing. Its docs list six connection paths: /chromium, /chrome and /stealth over CDP, and /firefox/playwright, /webkit/playwright and /edge/playwright for Playwright's native protocol. Whatever renders in Chrome renders here, including the parts of the page that only exist after layout.

Protocol compatibility is not the same as feature parity

Both projects speak the Chrome DevTools Protocol, and both use that as their headline compatibility claim. It is the reason Puppeteer and Playwright code can point at either without a rewrite.

Browserless states the case plainly in its docs: "Run your existing automation code by changing the connection URL to point at Browserless," and lists support for "Puppeteer, Playwright, Selenium, and CDP-based libraries including chromedp (Go), PHP cURL, and Python Pyppeteer." Because a real browser is on the other end, connect() and connectOverCDP() behave the way the library authors intended. Selenium works too, which matters more than it sounds like if you have a decade of WebDriver tests you are not going to rewrite.

Lightpanda ships a CDP and WebSocket server and documents Puppeteer and Playwright usage, but speaking the protocol only gets you to the handshake. A CDP server can answer just the commands its engine can implement. Page.captureScreenshot needs a rasterizer. DOM.getBoxModel needs layout. Scripts that stay inside navigation, evaluation, DOM queries and network interception port cleanly. Scripts that reach for the visual half of the protocol do not, and the failure arrives at runtime rather than at connect time.

In practice that means porting to Browserless is usually an edit to a connection string, while porting to Lightpanda is a migration with a test pass attached.

What the numbers actually say about cost

Lightpanda publishes a benchmark in its README and repeats it on its homepage. Running chromedp against 933 real web pages on an AWS EC2 m5.large instance, it reports peak memory of 123MB against headless Chrome's 2GB for 100 pages, roughly sixteen times less, and execution time of 5 seconds against 46 seconds for the same 100 pages, roughly nine times faster. Those are Lightpanda's own figures on Lightpanda's own harness, so read them as a claim rather than an independent result. Our guide to reading scraping benchmarks covers why vendor harnesses tend to flatter the vendor.

Even discounted, the direction is not really in dispute. An engine that never lays out or paints a page will use less memory than one that does. The question is what that converts to on an invoice, and here the two billing models matter more than the engine.

Browserless list pricing, read on 2026-07-27, bills in units. Its pricing page defines a unit as "a block of browser time of up to 30 seconds per browser connection," with additional units for every 30 seconds beyond. Free gives 1k units and 2 concurrent browsers. Prototyping is $25 a month billed annually for 20k units and 10 concurrent browsers. Starter is $140 for 180k units and 40 concurrent. Scale is $350 for 500k units and 100 concurrent, with overage at $0.0015 per unit. Proxy traffic is metered separately at 6 units per MB residential and 2 units per MB datacenter, and CAPTCHA solving costs 10 units per success.

Lightpanda list pricing, read the same day, bills browser hours. Explorer is free with 10 hours a month and 5 concurrent sessions. Builder is $19 a month for 300 browser hours and 30 concurrent sessions, with overage at $0.08 an hour. Enterprise is quoted, with on-premise and private cloud options mentioned.

Take a million pages and run the arithmetic on those list prices. Assume one page per browser connection and a render that finishes inside 30 seconds, and a million Browserless pages is a million units, which is around $1,500 at Scale overage rates before any proxy or CAPTCHA metering. Assume a second of engine time per page on Lightpanda and a million pages is 278 browser hours, which fits inside the $19 Builder allowance. At five seconds a page it is 1,389 hours, so $19 plus roughly $87 of overage.

Two caveats keep that from being a headline. The per-page durations are assumptions for the sake of arithmetic, not something we measured, and you should substitute your own numbers from your own targets. And the Browserless unit is a 30-second block per connection, which means the model rewards reusing one browser connection across many pages and punishes one-page-one-connection patterns. A crawler that batches fifty short renders through a single connection changes its own bill by an order of magnitude without changing vendors. That structural detail is worth more than most price comparisons; we walk through the same effect for API vendors in our guide to scraping API credit pricing and for owned fleets in headless Chrome fleet economics.

The general point still stands. Time-based billing compounds with a faster engine, unit-based billing does not. If Lightpanda renders your pages correctly, it is far cheaper. The conditional is doing all the work.

Self-hosting and licensing

Both can be run on your own hardware, which separates them from the fully managed end of the category.

Lightpanda is AGPL-3.0. The docs cover a one-line installer, Docker, package managers, nightly builds and building from source. The README flags two operational details worth knowing before you plan a deployment: there is no native Windows binary, so Windows means WSL2, and the Linux binaries link glibc, so Alpine and other musl distros need a rebuild. AGPL also has implications if you expose a modified build as a network service, which is a conversation for your legal team rather than this page.

Browserless publishes its core server under "SSPL-1.0 OR Browserless Commercial License," with Docker images at ghcr.io/browserless/chromium, plus firefox and multi variants. The open-source build covers parallelism, queueing, a debug viewer, font and emoji support and configurable timeouts. The README places the premium surface, including BrowserQL, session replay, residential proxies and the MCP server, behind a commercial license or a cloud subscription. So self-hosting Browserless is real, but the thing you self-host is not the thing you get on the managed plan. SSPL is also not an OSI-approved license, and some organizations treat it as a blocker on principle.

Either way, self-hosting moves cost rather than removing it. You inherit capacity planning, crash recovery, zombie process cleanup and the memory footprint that made you compare engines in the first place. Our guide on self-hosted versus managed browsers covers where that line usually falls.

Stealth is not a fair fight

Browserless has built evasion into the product. The docs describe a /stealth CDP endpoint, an /unblock REST endpoint "specifically designed to bypass bot detection mechanisms like Datadome and passive CAPTCHAs," and BrowserQL, a declarative GraphQL API the docs describe as including "built-in stealth capabilities, CAPTCHA solving, proxy rotation, and browser fingerprint randomization," with a privacy-hardened /stealth/bql variant for sites where the standard browsers get blocked.

Lightpanda documents proxy configuration and nothing comparable, which follows from the design rather than from neglect. Anti-bot vendors profile the browser, and a from-scratch engine that implements a subset of the Web platform is trivially distinguishable from Chrome on a fingerprint check. Every unimplemented API is a tell. This is the mechanism our guide on why scrapers get blocked describes, and the reason an anti-bot system is the wrong thing to fight with a minimal engine.

For public content pages with no serious protection, none of this matters and Lightpanda's economics win outright. For anything behind a commercial bot-management product, Browserless is playing the game and Lightpanda is not. If your targets are genuinely hostile, the honest comparison is not between these two at all; it is between Browserless and a proxy-backed unblocker, which is the ground covered in web unblocker vs scraping API and priced against the proxy networks category.

Maturity and the surrounding ecosystem

Browserless has been shipping managed browsers for years, has 13.5k GitHub stars on the core server, and sits inside a category with several credible alternatives if it does not fit: Browserbase, Steel, Hyperbrowser and Anchor Browser all target the same managed-Chromium job with different emphases. Our tools entry notes that scale and customer figures on the Browserless site are self-reported, so if you are counting on high concurrency, test it under your own load rather than trusting a number on a marketing page.

Lightpanda is newer and says so. Read the README's beta warning literally: it describes a project still filling in the Web platform. Its GitHub presence is large, around 32.7k stars, which measures interest in the idea rather than production hours. Its homepage names Vercel Labs, Dust, Nous Research and Trigger.dev among agent frameworks it works with, which is a partnership claim rather than an audited customer list, and we have not independently verified those relationships.

One nuance worth noting: Lightpanda's cloud offers a choice between its own engine and Chrome, described on the homepage as a way to "choose from Chrome or Lightpanda's browser to ensure all use cases are covered." That is a sensible hedge and it also concedes the central point. The lean engine is not a universal replacement, and the vendor's own product design assumes some fraction of your traffic will need a real browser.

Both fit the same place in a pipeline. A crawling framework like Crawlee or Scrapy handles scheduling, deduplication and retries; the browser layer only handles rendering. That separation is why swapping the render backend is tractable at all, and it is the same architectural split we describe in Scrapy vs Crawlee. If your workload is agent-shaped rather than crawl-shaped, the agentic automation category is a better starting point than either of these.

How to run the evaluation

Take a stratified sample of your targets, a few hundred URLs across every template you scrape. Render each one through Lightpanda and through Chrome. Diff the extracted fields, not the HTML. You now have the only number that matters: the share of your traffic a lean engine can serve.

If that share is above 90%, a split architecture is worth designing. Route the easy majority through Lightpanda, fall back to Browserless or another Chromium pool for the remainder, and accept the complexity of two code paths in exchange for a rendering bill that drops by most of its value. If the share is below half, the split is not worth maintaining and you should run one Chromium pool and spend your engineering time on the blocking layer instead.

Run the concurrency test separately. Both vendors gate concurrent sessions by plan, and a pool that is fast per page but capped at 30 concurrent sessions may be slower in wall-clock terms than a slower engine with 100.

Who each one is wrong for

Lightpanda is wrong for the team that needs screenshots or PDFs, that scrapes targets behind commercial bot management, that has a large existing Playwright suite using the visual half of the API, or that cannot carry a beta dependency in a revenue path. It is also wrong if your volumes are small, because at low scale the rendering bill is not the problem you have and the compatibility risk buys you nothing.

Browserless is wrong for the team whose entire cost problem is rendering volume on simple, unprotected content pages, where paying for a full browser to build a render tree nobody looks at is pure waste. It is also wrong if SSPL is a blocker in your organization, or if you want the managed feature set on your own hardware without a commercial license.

For a team rendering millions of pages a month the two are rarely mutually exclusive, and the compatible fraction decides whether you route across both or just buy Chromium and move on. If the rest of the stack is still open, choosing web scraping tools is the wider starting point.