Lightpanda Is the Headless Browser Built for AI Agents. It Never Draws the Page.

Why skipping the pixels makes it fast, where that breaks your agent, and the two settings to check first.

Every time an AI agent opens a web page through headless Chrome, a full browser engine lays out and paints a page that no human will ever see. Fonts get loaded. Images get decoded. Colors get blended into pixels that sit in memory and get thrown away.

For one page, nobody cares. For an agent that reads a few thousand pages a day, or a test suite that clicks through a signup flow on every commit, that invisible painting adds up to real memory and real time. One open source browser is betting agents never needed the paint at all.

Lightpanda is that bet. It's a headless browser written from scratch in Zig, with, in the project's words, no graphical rendering engine. It sat at #24 on Trendshift's board this afternoon, released 1.0.2 on October 23, and has roughly 37,000 to 38,000 stars depending on where you look.

That one design choice explains both why it's fast and where it will let you down. So the useful question isn't "is it faster than Chrome?" It's "does my agent ever need the pixels?"

What Lightpanda is, in plain terms

A headless browser is a browser with no window. Code drives it instead of a person: open this URL, click that button, read the text. Agents use one whenever an API doesn't exist and they have to work the website the way a human would.

Most teams reach for headless Chrome, driven by Puppeteer or Playwright (the two common JavaScript libraries for controlling a browser from code). Lightpanda is a different engine that speaks the same remote-control protocol. That protocol is CDP, the Chrome DevTools Protocol, the channel Puppeteer and Playwright already use to talk to Chrome. Point your existing script at Lightpanda's address instead of Chrome's, and much of it can keep working.

Under the hood, the README lists what it does build: an HTML parser (html5ever), a DOM tree (the browser's internal model of the page), JavaScript through V8 (the same JavaScript engine Chrome uses), XHR and Fetch (the two ways page scripts call servers), cookies, form input, clicks, proxy support and network interception. It also speaks WebDriver BiDi, a newer browser-control standard.

What it skips is the drawing.

Why skipping the paint makes it fast

Think about the difference between reading a recipe and cooking it. Headless Chrome cooks every dish, plates it, and then throws it away because nobody was going to eat it. Lightpanda reads the recipe, keeps the ingredient list, and moves on.

For an agent that mostly wants text, links and form fields, the recipe is enough.

The project claims Lightpanda is "16x lighter and 9x faster than Chromium." The README backs that with 123 MB of peak memory against 2 GB for headless Chrome, and about 5 seconds against 46.

Read those as the project's measurements, not a neutral test, and read the fine print. The benchmark notes show where the headline comes from: a crawler fetching 933 pages from Lightpanda's own demo site over the network, run as 25 Lightpanda processes against 25 Chrome tabs. The README labels the same figures "100 pages," which doesn't match. Lightpanda used processes because, the notes say, it "can't open multiple tabs." A second test loaded a homemade product page 100 times from a local server through Puppeteer, and there Lightpanda averaged 16 milliseconds a load against Chrome's 185. Chrome was version 143 in headless mode. One more mismatch: the README names an m5.large AWS instance while the notes name an m5.xlarge. None of this sinks the result. All of it is a reason to run your own pages before you plan capacity around 16x.

Where skipping the paint breaks your agent

Here's the insight to carry into any decision about this tool: Lightpanda is a text-and-DOM browser. Anything your agent learns from how a page looks, rather than what the page says, is where it gets weaker.

The clearest example is screenshots. Lightpanda's MCP tools reference says its screenshot tool "shows text layout only. It omits images, fonts, and CSS colors." If your agent uses a vision model to look at the page, or your test checks that a button is red, you'll get a sketch, not the page.

The same docs flag a timing trap. After goto, "content loaded by later JavaScript may be missing," and the fix is to wait for the network to go quiet (waitForState with networkidle) and read again. Chrome users hit this too, but it matters more when you're trying a new engine and blaming it for empty reads.

And the project doesn't publish a list of unsupported web features. The README points to Web Platform Tests results (the shared test suite browser makers use) for compliance details instead. That's honest, but it means you find gaps by running your sites, not by reading a page.

There's a quiet tell in Lightpanda's own cloud service. Its Playwright guide shows that the hosted endpoint accepts browser=chrome to give you Google Chrome instead. The company that built the lighter engine still keeps Chrome on the menu. That tells you how they expect people to use it: Lightpanda where it works, Chrome where it doesn't.

Put this into practice

The fastest way to learn whether Lightpanda fits is a one-hour bake-off on your agent's real target sites.

1. Install it. On macOS or Linux (Homebrew installs the nightly build):

brew install lightpanda-io/browser/lightpanda

Or run it in Docker, bound to your own machine only (pin a version tag instead of latest once you deploy for real):

docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:latest

The README notes that the Linux release binaries need glibc, the standard C library on most Linux distributions, so they won't run directly on Alpine, which uses a different one called musl (build from source there), and Windows has no native binary, so it needs WSL2.

2. Turn telemetry off before your first real run. The README says plainly: "By default, Lightpanda collects and sends usage telemetry." If your agent visits internal tools or customer pages, set this first:

export LIGHTPANDA_DISABLE_TELEMETRY=true

3. Try the one-shot fetch. This is the smallest useful test. It loads one page and prints what Lightpanda saw:

lightpanda fetch --obey-robots --dump markdown https://example.com

Swap markdown for html to see the raw DOM. If the markdown for your target page has the text your agent needs, that's a good sign.

One habit worth keeping from the start: bind serve and mcp --port to 127.0.0.1, as the commands below do. Anything that can reach that port can drive the browser.

4. Point your existing script at it. Start the server:

lightpanda serve --host 127.0.0.1 --port 9222

Then connect Playwright the way the docs show:

import { chromium } from 'playwright-core';
const browser = await chromium.connectOverCDP('ws://127.0.0.1:9222');

Run your agent's real flow against Lightpanda and against Chrome. Compare three things: did the agent get the same text, did every click and form fill work, and how much memory did each use?

5. Or give it to your agent directly. Lightpanda ships an MCP server, MCP being the Model Context Protocol, the standard way agents like Claude Code discover and call tools. lightpanda mcp runs it over stdio, and lightpanda mcp --port <PORT> runs it over HTTP. The tools include goto, markdown, click, fill, extract and waitForState. One catch from the docs: the session_new and session_list tools only work over HTTP; on stdio you get a single default session.

What to expect: on text-heavy pages (docs, search results, simple dashboards), you'll likely see the same content with far less memory. On pages built around canvas drawing, heavy visual layout or image-based checks, you'll see where the paint mattered.

A simple rule for which browser gets which job

You don't have to pick one browser for everything. Most agent stacks have two kinds of browsing mixed together, and they want different engines.

Give Lightpanda the reading jobs. Pulling docs pages into context, walking search results, crawling a site for links, filling a form on a page that renders its content as HTML, and smoke-testing that a page loads and says the right words. These jobs care about the DOM and the text. They also tend to run in volume, which is exactly where memory per page decides how many agents fit on one machine. If 25 Chrome tabs take about 2 GB in the project's crawl and 25 Lightpanda processes take about 123 MB, the difference shows up as how many parallel workers your box can hold, not as a nicer number on a chart.

Keep Chrome for the looking jobs. Anything that feeds a screenshot to a vision model, checks layout or color, depends on canvas or WebGL drawing (the APIs pages use to paint charts, maps and games pixel by pixel), or has failed your bake-off. Also keep Chrome anywhere you haven't tested yet. A wrong answer from a browser that silently skipped something costs more than the memory you saved.

The routing itself can be boring. Two CDP addresses, one environment variable per job type, and a fallback that retries on Chrome when Lightpanda returns an empty or obviously short read. That last check is cheap, and it catches most of the cases where a page needed something Lightpanda doesn't do.

Honest limitations

It's AGPL-3.0. The LICENSE file is the GNU Affero General Public License. Running it as a tool inside your own pipeline is one thing. If you modify Lightpanda and let other people use it over a network, the AGPL can require you to share your changes. Check with whoever handles licensing before you build a product on it. Contributions also require signing a contributor license agreement.

Telemetry is opt-out, not opt-in. Covered above, and easy to forget in a container where nobody reads the README.

No vision, no pixels. If your agent's decisions depend on screenshots, Lightpanda's text-layout screenshot won't carry them.

The speed claim is self-measured. It's a clear, documented benchmark, but it's the vendor's, on its own demo pages, with one setup inconsistency between the README and the notes.

Platform gaps. No prebuilt Alpine (musl) binaries, and Windows only through WSL2.

Compatibility is learned by testing. Without a published list of unsupported features, budget time for finding the sites that break.

Where this leaves you

The headless browser has been a default nobody questioned: if an agent needs the web, it gets Chrome. Lightpanda makes that a choice. For agents that read, click and extract, a browser that never draws can do the same job with a fraction of the memory. For agents that look, it can't.

So run the bake-off. Pick ten pages your agent actually visits, turn telemetry off, and compare what comes back. Your own pages will answer the question better than any benchmark, including this one's.

Sources: lightpanda-io/browser README and LICENSE (reviewed at release 1.0.2, Oct 23, 2026); Lightpanda benchmark notes; Lightpanda MCP tools reference; Lightpanda Playwright guide; star count from shields.io and the repo page, Oct 29, 2026; Trendshift daily board, Oct 29, 2026.