The Scene
By 2026, Chromium-based browsers hold roughly 70% of the market, WebKit around 20%, and Firefox under 10%. Chrome, Edge, Brave, Arc, and Vivaldi all sit on Chromium. That's no coincidence—building a browser engine is hard, and building one from scratch is even harder.
Ladybird insists on doing exactly that. Its self-description is one sentence: "A truly independent web browser, using a novel engine based on web standards." Not a fork, not a wrapper, not a re-packaged Chromium. Built from zero.
Not a Fork — From Scratch
"From scratch" carries enormous weight in the browser world. Chromium exceeds 30 million lines of code; Firefox's Gecko is tens of millions more. A new engine must support HTML5, CSS3, ES2025, WebAssembly, WebGL, WebGPU, WebRTC... each a massive engineering effort.
Ladybird's origin is unusual. It began as part of SerenityOS—a Unix-like OS started single-handedly by Andreas Kling in 2019. SerenityOS wrote its own web rendering engine (LibWeb), JavaScript engine (LibJS), and WASM implementation (LibWasm), because the OS needed a browser anyway.
In 2024, Ladybird became an independent browser project backed by a 501(c)(3) non-profit. Kling's philosophy is explicit: no user monetization, no ads, no data collection—just a browser.
Multi-Process Architecture
Ladybird uses a multi-process design:
- Main UI process: windows, tabs, user interaction
- WebContent renderer: one per tab, isolated from each other
- ImageDecoder process: image decoding out-of-process, guarding against malicious content
- RequestServer process: network requests out-of-process
- Lua beside Python—not a replacement, a different set of design trade-offs
- FreeBSD beside Linux—a different kernel architecture reference
- ARM/RISC-V beside x86—a different ISA design reference
- GitHub: https://github.com/LadybirdBrowser/ladybird
- Website: https://ladybird.org
- Status: pre-alpha
- Architecture: multi-process (UI + WebContent + ImageDecoder + RequestServer)
- Core libraries: LibWeb / LibJS / LibWasm / LibCrypto / LibTLS / LibHTTP / LibGfx / LibUnicode / LibMedia / LibCore / LibIPC
- License: 2-clause BSD
- Platforms: Linux / macOS / Windows (WSL2) / *Nix
- Organization: 501(c)(3) non-profit
This mirrors Chromium's multi-process philosophy—isolating untrusted content into sandboxed processes. Image decoding and network connections are major attack surfaces; keeping them out-of-process means a compromise can't directly reach the main process.
Ladybird inherits a large set of core libraries from SerenityOS:
| Library | Role | |---|---| | LibWeb | Web rendering engine | | LibJS | JavaScript engine | | LibWasm | WebAssembly implementation | | LibCrypto/LibTLS | Crypto primitives and TLS | | LibHTTP | HTTP/1.1 client | | LibGfx | 2D graphics, image decoding and rendering | | LibUnicode | Unicode and locale support | | LibMedia | Audio/video playback | | LibCore | Event loop, OS abstraction | | LibIPC | Inter-process communication |
These cover every core component of a browser engine. Inheriting from SerenityOS is not a weakness—the code has iterated for over five years and is quite solid.
Why Build a New Engine in the Chromium Era
1. Monopoly risk. When only one engine implements the web platform, its bugs become the "standard." Developers code to Chromium's behavior instead of W3C specs—just like the IE6 era. One dominant implementation means stalled innovation and hollow standards. Firefox/Gecko survives, but its share keeps shrinking. Ladybird pushes back.
2. Independent implementations expose standards flaws. When two independent implementations follow the same spec, ambiguities and gaps surface. That's a key driver of web standards evolution—without independent implementations, the standard becomes "whatever Chromium does."
3. Non-profit governance. Chromium is backed by Google (a commercial company); Firefox by Mozilla (a non-profit dependent on Google search revenue). Ladybird is backed by a 501(c)(3) non-profit explicitly refusing monetization—a new governance structure in the browser space.
4. Technical exploration. LibWeb is a from-scratch rendering engine with no legacy burden, free to try designs that Chromium/Gecko can't risk due to compatibility constraints.
Current Status: Pre-Alpha
Ladybird is explicitly pre-alpha, suitable only for developers. This is not modesty—writing a modern browser engine from scratch is a colossal effort. It can render many pages but is far from daily-driver quality.
It runs on Linux, macOS, Windows (WSL2), and various *Nix systems, under a 2-clause BSD license friendly to commercial use.
The Value of Independent Implementations
Ladybird illustrates a recurring pattern: the value of an independent implementation is not replacing the mainstream, but providing a reference frame.
Ladybird plays the same role for Chromium. It doesn't need to win—its existence itself has value. When the web platform has only one engine, the "standard" becomes the implementation. Each independent implementation makes standards meaningful.
Key Facts
Why It's Worth Watching
Ladybird is the only browser engine project in 2026 that is from scratch, non-fork, and non-profit. Its engineering burden is enormous, and it may never "beat" Chromium. But its existence alone matters: it provides an independent reference for the web platform, new design space for browser architecture, and a model of non-commercial governance for open source. In an era where every browser increasingly resembles Chromium, a truly independent engine deserves attention—even if you never use it, its existence makes web standards more meaningful.