Exploring Ladybird, the Non-Chromium Browser Project

Ladybird is a web browser engine built from scratch — no Chromium, no WebKit, no Gecko lineage — developed by the Ladybird Browser Initiative, a 501(c)(3) non-profit founded by Andreas Kling and Chris Wanstrath. It is the first genuinely new independent browser engine in over a decade to reach a level of standards conformance that makes it worth a frontend developer’s attention. This article answers the three questions a developer actually has after seeing “Ladybird” trend on Hacker News or X: is it real, is the 2026 alpha meaningful, and does it change anything about the web you ship to. The short version is yes, plausibly, and not yet — but the trajectory is the interesting part.

What Ladybird Is, and Who Is Building It

Ladybird is an independent browser engine with no shared code from Blink, WebKit, or Gecko, governed by the Ladybird Browser Initiative — a registered 501(c)(3) non-profit. According to the project’s organization page, current leadership comprises Andreas Kling as President, Tim Flynn as Secretary, and Mike Shaver as Treasurer. The project began as the HTML viewer inside SerenityOS, Kling’s hobby operating system, before splitting off into a standalone cross-platform browser.

The governance structure is a stronger “is this real” signal than any feature list. Ladybird is funded through sponsorships and donations rather than advertising or device sales. Chris Wanstrath — co-founder of GitHub — co-founded the Initiative and his family pledged $1 million to it, as announced on awesomekling.github.io. The project’s sponsor roster, listed on ladybird.org (retrieved April 2026), includes Platinum-tier sponsors FUTO, Shopify, and Cloudflare, and Gold-tier sponsors including the Human Rights Foundation, Proton, Guillermo Rauch, and Ohne Makler. Verify the current tiering against the site, as it changes as the project grows.

This is the answer-unit that matters most for skeptics: a named legal entity, named officers, named corporate sponsors, and a verifiable funding pledge. Ladybird is not a weekend prototype.

Why a New Browser Engine Is Rare

The web runs on three engines — Google’s Blink, Apple’s WebKit, and Mozilla’s Gecko — and a genuinely new one is rare because the cost of entry is enormous. The last time a new independent engine reached meaningful adoption, Opera was still shipping Presto; that ended in 2013 when Opera switched to a Chromium-based browser, and Microsoft’s transition away from EdgeHTML culminated with the stable release of Chromium-based Edge in 2020. Today, the web is largely dependent on those three rendering engines, with Blink holding the dominant share of browser usage per StatCounter.

Building a new engine is exceptionally difficult because it must pass tens of thousands of compatibility tests and correctly handle HTML, CSS, JavaScript, graphics, security, accessibility, and performance at web scale. The benchmark for that surface is the Web Platform Tests (WPT) suite, a cross-vendor conformance project. WPT contains millions of individual subtests; matching the behavior real-world sites depend on — including undocumented quirks that established engines have shipped for decades — is the work that has historically killed independent engines. A strict standards implementation that breaks sites relying on those quirks fails the only test that matters commercially: rendering the existing web.

That is the context that makes Ladybird notable. It is not competing on features. It is attempting to clear the conformance bar that the consolidation of the last decade made nearly insurmountable.

Inside the Ladybird Architecture

Ladybird’s multi-process architecture separates rendering, image decoding, and network requests into distinct sandboxed processes, coordinated over inter-process communication. Per the project’s documentation and source layout, the engine splits into a main UI process and a set of helper processes: WebContent handles rendering and script execution, ImageDecoder decodes images, and RequestServer handles network requests. Each web content process runs sandboxed.

The point of this split is containment at a process boundary. Decoding untrusted image data — a historically common source of memory-corruption bugs — happens in ImageDecoder, isolated from the rendering process. Network handling lives in RequestServer, isolated from page content. The process separation itself is the verifiable design claim; the boundaries are where Ladybird’s security model lives, modeled on the multi-process designs that mainstream browsers adopted over the last fifteen years.

The rendering and scripting work is divided across a set of libraries, each scoped to a layer of the platform:

LibJS is worth singling out because it is not a thin wrapper over an existing JavaScript engine like V8 or JavaScriptCore — it is a complete implementation with its own lexer, parser, AST, bytecode generator, and bytecode interpreter. That detail matters for the next section, because the frontend of that pipeline is where the project’s most significant recent engineering work landed.

Language Strategy: C++ Core, Rust Underway

Ladybird’s core is written in modern C++, but the team has begun migrating performance- and safety-sensitive components to Rust. In February 2026, the project landed a Rust reimplementation of the LibJS frontend pipeline — covering the lexer, parser, AST, scope collector, and bytecode generator — with the Rust pipeline enabled by default, as reported in the February 2026 newsletter. This is the freshest and most technically significant development in the project, and it is absent from earlier coverage.

The motivation is the standard one for Rust adoption in a browser engine: memory safety in code paths that parse untrusted input. A JavaScript parser ingests arbitrary attacker-controlled text on every page load, making it exactly the kind of component where a memory-safety guarantee at the language level reduces a whole class of vulnerabilities. Well-defined interop boundaries also make incremental migration feasible — the Rust frontend can hand bytecode to the existing C++ interpreter without a wholesale rewrite.

This was not the project’s first experiment beyond C++. Ladybird previously explored Swift for parts of the codebase and later removed all Swift code before committing to Rust. The shift from “we’re trying Swift” to “the Rust frontend pipeline ships by default” is a marker of engineering maturation: the project is now making and reversing language decisions deliberately rather than treating C++ as a permanent given.

Standards Conformance: Where Ladybird Stands

As of April 2026, Ladybird reported 2,067,263 passing Web Platform Test subtests — up from 2,003,537 the prior period — per the April 2026 newsletter, alongside a 97.8% pass rate across 52,045 of 53,207 imported test262 JavaScript conformance subtests. These numbers are the clearest evidence that Ladybird is a serious engine rather than a demo.

A few caveats keep these numbers honest. The WPT subtest count is an absolute figure, not a percentage of the full suite; for an overall WPT pass-rate ranking against other engines, verify directly against wpt.fyi with a stated retrieval date, since the suite size and per-browser results move continuously. The test262 figure is scoped to imported subtests, not the entire suite — Ladybird imports a subset and reports against that. With those qualifications, the picture is a JavaScript implementation passing the overwhelming majority of the conformance tests it runs, and a web platform implementation clearing millions of WPT subtests. That is well past the threshold where an engine renders the real web at all.

Roadmap and Honest Caveats

The official site targets a public alpha in 2026 for Linux and macOS, per the Ladybird homepage. Beta and stable release dates have circulated in secondary coverage as 2027 and 2028 respectively, but these cannot currently be verified from ladybird.org and should be treated as indicative rather than committed. Pre-alpha timelines slip, and a browser engine’s conformance work is open-ended by nature, so any date past the 2026 alpha is a target rather than a promise.

Platform support is narrower than a finished browser but broader than “Linux only.” The alpha targets Linux and macOS; Windows support is under active development, and WSL2-based build workflows already exist for developers on Windows who want to run the engine today. The practical state, as of this writing, is software that builds and runs but is not ready for daily browsing — expect missing features and rough edges.

Why Ladybird Matters to Frontend Developers

A fourth independent browser engine matters to frontend developers as a conformance pressure point, not as a new browser to ship to. A project that passes WPT strictly and files spec issues when real-world sites break creates accountability that a two-or-three-engine oligopoly does not. The value is structural, not about market share.

Because Ladybird’s non-profit structure has no advertising revenue to protect and no device ecosystem to defend, it is the only engine targeting a full end-user browser with no structural incentive to deviate from W3C specifications toward a commercial agenda. Servo, originally from Mozilla and now under the Linux Foundation, shares this non-commercial posture but is currently developed as an embeddable engine rather than a full browser product. The distinction becomes concrete when you recall that FLoC was a Google Privacy Sandbox proposal later replaced by Topics, and that Intelligent Tracking Prevention is a WebKit feature reflecting Apple’s platform priorities. Both reflect the commercial context of their parent organizations; an engine with no such context removes that pressure entirely.

Engine-specific rendering and scripting quirks — CSS layout edge cases, JavaScript behavior differences at the spec margins — are the class of bug that surfaces in production traffic across a heterogeneous browser population, not in local testing against a single engine. Session replays of cross-browser issues frequently reveal failures that never reproduced on the developer’s own machine. More independent implementations passing the same conformance suite narrow the space where those quirks can hide.

How to Follow and Try Ladybird

Ladybird is pre-alpha software that builds and runs on Linux and macOS. The authoritative way to track it is the project’s own channels — secondary coverage goes stale within weeks. The ladybird.org/news feed publishes regular newsletters with conformance numbers, architecture changes, and milestone updates — it is the primary source for every status claim in this article. The source lives in the LadybirdBrowser/ladybird repository on GitHub.

To build and run it, follow the current build instructions in the official documentation rather than any third-party walkthrough — dependency lists and build commands change frequently in a project moving this fast. After cloning and installing dependencies, the project’s build-and-run entry point is its Meta script:

git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird
./Meta/ladybird.py run

The ./Meta/ladybird.py run form supersedes older ladybird.sh commands seen in stale tutorials. Treat any specific dependency version you find outside the official docs with suspicion; check the build instructions for the current toolchain requirements before you start.

Ladybird is a real, well-governed, from-scratch browser engine that is clearing serious conformance bars — not a viable Chrome alternative today, but the most credible attempt at engine diversity the web has seen in over a decade. The concrete next action is to bookmark ladybird.org/news and check the conformance numbers each newsletter; the trajectory of those figures will tell you more about whether this changes the web you ship to than any single snapshot can.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.