Ladybird

Ladybird is a new web browser engine built entirely from scratch with no code inherited from any existing browser. Unlike every other mainstream browser that traces its lineage to either Blink (Chrome, Edge, Opera) or WebKit (Safari), Ladybird writes its own HTML parser, CSS engine, JavaScript interpreter, WebAssembly runtime, TLS stack, and graphics library. The project originated as part of SerenityOS and was spun off as an independent effort in 2024, backed by a nonprofit foundation funded entirely by donations and sponsorships.

The browser uses a strict multi-process architecture where each tab runs in its own sandboxed WebContent process, with network requests and image decoding handled by separate processes that are isolated from the renderer. This design limits the damage any compromised web content can do. At the time of writing, Ladybird is in a pre-alpha state intended for developers and contributors — a public alpha is targeted for 2026.

The codebase is undergoing a strategic migration from C++ to Rust, using cbindgen to bridge Rust library crates into the C++ host layer. Core libraries including LibGfx, LibJS, LibRegex, LibUnicode, LibURL, LibWasm, and LibWeb are gaining Rust implementations incrementally. Standards compliance is driven by daily WPT (Web Platform Tests) runs that exercise hundreds of thousands of specifications against the engine.

What You Get

• Multi-process sandboxed architecture - Each tab spawns a dedicated WebContent process sandboxed from the OS, with RequestServer and ImageDecoder running in separate processes to limit exposure from malicious web content.
• LibWeb — custom HTML/CSS rendering engine - A complete web rendering engine written from scratch implementing the HTML living standard, CSS cascade, layout engine, Compositor, and ARIA accessibility tree with no Blink or WebKit code.
• LibJS — standalone JavaScript engine - A self-contained JavaScript implementation supporting modern ECMAScript features, with a bytecode interpreter and an in-progress JIT compiler, built without V8 or JavaScriptCore.
• LibWasm — native WebAssembly runtime - A from-scratch WebAssembly execution engine implementing the spec without reusing LLVM WebAssembly tools or any other browser’s Wasm infrastructure.
• LibGC — custom garbage collector - A precise garbage collector purpose-built for DOM graph cycles, replacing general-purpose allocators with a cell-based tracing GC that understands web object ownership patterns.
• Progressive Rust migration - Core libraries are being incrementally rewritten in Rust with cbindgen-generated C headers bridging Rust crates into the C++ build, improving memory safety without a full rewrite.
• WPT-driven specification compliance - Development is guided by daily Web Platform Test runs covering hundreds of thousands of test cases, using a custom test-web runner that executes Layout, Ref, Text, and Screenshot tests.
• Multi-frontend UI support - Supports Qt6, GTK4, macOS AppKit, and Android frontends through a shared LibWebView abstraction layer, enabling Ladybird to run natively on major desktop and mobile platforms.

Common Use Cases

• Browser engine research - Compiler engineers, systems programmers, and computer science researchers use Ladybird to study a clean-room browser implementation without inherited legacy complexity from Chromium or WebKit.
• Web standards interoperability testing - Web developers run their pages against Ladybird to catch non-standard behaviors that only show up in Chromium or Safari, improving cross-engine compatibility before shipping.
• Open web advocacy and browser diversity - Organizations and individual contributors sponsor or contribute to Ladybird to reduce browser engine monoculture and ensure the web platform is not controlled by a single vendor.
• Systems programming education - Students and practitioners learning C++ or Rust study Ladybird’s codebase as a real-world example of a large multi-process system with custom memory management, garbage collection, and network programming.
• Security research on browser attack surfaces - Security researchers analyze the sandboxing mechanisms and IPC design of a fresh-slate browser codebase unaffected by decades of accumulated CVEs and legacy attack surfaces.

Under The Hood

Architecture Ladybird uses a multi-process security architecture with strict trust boundaries enforced at the OS level. The main browser UI process spawns isolated WebContent renderer processes per tab, each sandboxed using platform mechanisms such as pledge/unveil on OpenBSD-derived systems and seccomp on Linux. Network access is delegated entirely to a separate RequestServer process, and every image decode happens in a fresh ImageDecoder process that is destroyed after completion. Within LibWeb, the design separates HTML parsing, CSS cascade resolution, layout tree construction, compositing, and JavaScript execution into distinct subsystems with well-defined ownership semantics. A code-generation pipeline transforms Web IDL specifications into C++ bindings automatically, keeping API surface synchronized with the living standards mechanically rather than manually.

Tech Stack The primary implementation language is C++23, with Rust being progressively adopted across core library crates including LibGfx, LibJS, LibRegex, LibUnicode, LibURL, LibWasm, and the LibWeb HTML parser. Rust crates are compiled as static libraries and bridged to C++ via cbindgen-generated headers. The build system uses CMake 3.30 with Ninja and vcpkg for package management. UI frontends are available for Qt6, GTK4, macOS AppKit, and Android using Kotlin and Java. Testing uses a custom test-web binary integrated with CMake/CTest and CI runs with AddressSanitizer and UndefinedBehaviorSanitizer enabled. No external web frameworks, databases, or cloud SDKs are used — the entire browser stack is self-contained.

Code Quality Ladybird’s codebase follows a consistently enforced style with clang-format and clang-tidy run in CI, and Rust components use Clippy with a comprehensive deny ruleset covering correctness, style, complexity, and performance lints. Testing is structured around WPT-compatible Layout, Ref, Text, and Screenshot test categories in Tests/LibWeb, augmented by C++ unit tests for internal libraries using a homegrown LibTest framework. CI runs sanitizer builds to catch memory errors and undefined behavior early. The codebase carries abundant FIXME and TODO annotations that trace active implementation work against specific web specification sections, giving the codebase a living quality that makes progress and gaps transparent. Naming conventions are consistent — CamelCase for types, snake_case for variables and functions — and the explicit smart-pointer style (RefPtr, WeakPtr, GCPtr) makes ownership semantics visible at the call site.

What Makes It Unique Ladybird is the first credible attempt in decades to ship a complete browser engine with zero shared lineage with any existing engine. Every component — garbage collector, JavaScript interpreter, WebAssembly runtime, TLS library, CSS cascade engine, image decoders, and font renderer — was written specifically for this project. The incremental Rust migration strategy is architecturally distinctive: rather than rewriting all at once, individual library crates are replaced in Rust with cbindgen bridges allowing the C++ core to call Rust code transparently, giving the project a realistic path to memory safety without stopping feature development. The WPT integration embedded in the CI pipeline means the engine is tested against the web platform specification itself on every commit, making standards compliance a first-class engineering metric rather than an afterthought.

Self-Hosting

Ladybird is released under the BSD 2-Clause license, one of the most permissive open-source licenses available. It imposes no copyleft obligations and places no restrictions on commercial use, modification, private deployment, or redistribution beyond requiring that the copyright notice and disclaimer be preserved in source and binary distributions. There are no dual-licensing tiers, no enterprise editions, and no commercial agreements required to use or redistribute Ladybird.

Running Ladybird from source requires a C++23-capable compiler (clang-21 or gcc-14 are used in CI), CMake 3.30, Ninja, a Rust toolchain, and platform-specific Qt6 or GTK4 development libraries. Because the project is in a pre-alpha state with no binary releases, every deployment currently means building from source. The process is well-documented with detailed per-platform build instructions, but it is not trivial — expect a substantial build time on the first run. There is no managed hosting, no Docker image for end-users, and no package manager distribution yet. Operational responsibility for maintaining a working build as the codebase evolves rapidly lies entirely with the operator.

There is no hosted cloud version, no SaaS tier, and no paid support offering. The project is run as a nonprofit and all development decisions are made openly on GitHub and Discord. For production or consumer use, Ladybird is not yet a viable alternative to mainstream browsers — its target audience at this stage is developers, contributors, and early adopters who want to follow or participate in the build of an independent engine. Anyone evaluating Ladybird as a deployment option should treat it as a research project and plan for frequent breaking changes and incomplete standards coverage until the 2026 alpha milestone is reached.