A browser engine you can watch being built
Ladybird is attempting the rarest kind of open-source software project: a new general-purpose web browser with its own engine. It does not use Blink, WebKit, Gecko, or another existing engine as its base. Several core libraries came from SerenityOS, including the LibWeb renderer and LibJS JavaScript engine, but Ladybird now develops as a separate browser and uses outside libraries where that makes sense.
The architecture already resembles a modern browser. A main UI process coordinates separate WebContent renderer processes, with image decoding and network work moved into their own processes. Each tab gets a sandboxed renderer. That separation is meaningful when parsing hostile pages, although nobody should mistake an architectural choice for a finished security record. The README's warning is blunt: Ladybird is pre-alpha and only suitable for developers.
That makes its present value easier to judge. Browser engineers can read a fresh implementation of web standards. Web developers can try real sites, reduce failures, and file useful reports. Curious users can see how far an independent engine has come. People who simply need another private daily browser should wait. Compatibility, stability, packaging, and polish are still moving targets.
What happened when we ran it
We cloned commit 1933563 into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The lab identified a Python ecosystem path, installed 33 packages in 13 seconds, and measured 36 MB of installed dependencies. Its detected build completed in 5 seconds. The Python dependency audit reported no known vulnerabilities.
The harness found no test script or target, so it skipped tests. That is an important limit on the result. Ladybird's repository contains extensive C++ browser code and its official build requires Qt, Rust, CMake, Ninja, and a suitable compiler. A 5-second success on the detected path cannot prove that the full browser was compiled, launched, or passed its own engine test suites. It records only what the sandbox reached.
The checkout itself was substantial: 28,242 files, about 1,553,307 lines of source, and 161.5 MB. There were 16 CI workflow files, no Dockerfile, and no top-level tests directory detected by the lab. The CI footprint shows active automation, while the absent detected test target means our run provides no independent compatibility or regression result.
The source build requires Qt 6.9 and CMake 3.30
The website presents a 3-command path: clone the repository, enter it, and run ./Meta/ladybird.py run. The detailed instructions reveal the host preparation behind that tidy example. You need Qt 6.9 or newer, CMake 3.30 or newer, a Rust toolchain, nasm, Ninja, graphics and audio development packages, and a C++23-capable compiler. Ladybird's CI currently uses gcc 14 and clang 21.
Distribution age matters. The docs specifically warn that Debian 13 provides Qt 6.8, which is too old to configure Ladybird. Ubuntu users may need Kitware's CMake repository and LLVM's package repository. Windows users are directed to WSL2; the native Clang-CL path is experimental and has limited functionality. WSL1 and MinGW are unsupported. Linux and macOS are the platforms a prospective tester should choose.
The build helper manages much of the compilation, yet local failures can still demand CMake and vcpkg log reading. The documentation calls out a misleading Ninja error that can really mean a third-party dependency failed. It also explains how to cap parallel link jobs on machines with limited memory. Resource placement is another packaging concern: icons, fonts, and themes depend on files copied from the base resource directory, and an incorrect CMake data path breaks them.
Non-maintainers cannot submit code pull requests
Ladybird is open source under the 2-clause BSD license, but it does not accept code pull requests from non-maintainers. The project asks outside contributors for bug reports, reduced test cases, website testing, standards discussion, security reports, and technical feedback. That is a deliberate governance choice, and it changes the pitch for developers who expect to fix an issue and submit the patch themselves.
The repository is plainly active. Its last push was August 27, 2026, and issues and pull requests were being updated the same day. Current work included certificate-chain handling on Linux, renderer state, WebRTC audio, and response cleanup. GitHub showed 536 open issues and pull requests combined, which is a work queue rather than a count of confirmed bugs. The project has not published a GitHub release.
The public target is a first alpha for Linux and macOS in 2026, aimed at developers and early adopters. The website says Windows support will follow later and mobile is not a current focus. Those are stated targets, not evidence that a general-user release is ready.
Ladybird is for browser work, not daily browsing
Choose Ladybird when the work itself is browser research, standards testing, or early compatibility feedback. Its independent engine and readable development process make it more interesting than another shell around Chromium. The active repository and detailed build notes also give serious testers enough material to get oriented.
Do not choose it as the browser layer for a product, a managed desktop fleet, or ordinary family use. There are no normal release artifacts, the supported build path asks for current native toolchains, and the maintainers explicitly restrict the audience to developers. Servo is a closer experimental comparison, especially for Rust and embedding. Chromium and WebKit are the practical choices when compatibility and production history decide the purchase. Ladybird earns attention now, while daily use should wait for evidence from an actual alpha.