Ladybird calls itself pre-alpha in a callout box, and that is the honest summary

The status callout is the first thing after the title, and it says pre-alpha

The README opens with a one-sentence definition, that Ladybird is a truly independent web browser using a novel engine based on web standards. The next element on the page is a callout marked important, and it reads: Ladybird is in a pre-alpha state, and only suitable for use by developers.

That sentence is the most useful thing in the document and it costs the project nothing to say, because the alternative is a reader who installs it, finds three websites that do not render, and concludes the project is dishonest. Pre-alpha is a specific claim: the architecture exists and runs, the web platform is partially implemented, and the result is not a browser you would hand to anyone else.

The features section reinforces the framing with a stated aim rather than a claim: we aim to build a complete, usable browser for the modern web. Aim, not achievement. Combined with the callout, that tells a reader exactly what kind of project this is, and it tells them what kind of contribution the project wants. If you were looking for a browser, this is the wrong repository. If you were looking for a place to work on a browser engine, the callout is an invitation rather than a warning.

Windows support means WSL2, so there is no native Windows build

The platform sentence is one line: Ladybird runs on Linux, macOS, Windows with WSL2, and many other Nixes. The parenthetical is doing all the work in that sentence.

WSL2 is a Linux compatibility layer, not a port. Running Ladybird on Windows means running a Linux binary inside that layer, with the layer providing the kernel interface. That is a real constraint with real consequences, and they are not the ones a Windows user expects. You are not getting a Windows browser that happens to have the same user interface; you are running a program built for a different operating system through a translation and virtualisation layer, and every bug you report will need to be triaged against that layer before anyone can tell whether it belongs to Ladybird.

The project states this plainly rather than implying native support, which is the right call and unusual. Most projects list Windows in a platform list and leave the parenthetical out. Here the parenthetical is in the same sentence as the claim, so a reader cannot come away thinking there is a native build. For a browser project whose entire premise is being independent of the dominant engine, running on a layer that emulates another operating system is an obvious tension, and the README does not pretend otherwise.

The core libraries come from SerenityOS, and the README qualifies it with at the moment

The features section states that many core library support components are inherited from SerenityOS, and then names ten of them. LibWeb is the web rendering engine. LibJS is the JavaScript engine. LibWasm is the WebAssembly implementation. LibCrypto and LibTLS cover cryptography primitives and transport layer security. LibHTTP is an HTTP/1.1 client. LibGfx is the 2D graphics library, image decoding and rendering. LibUnicode handles Unicode and locale support. LibMedia handles audio and video playback. LibCore is the event loop and OS abstraction layer. LibIPC is inter-process communication.

Two things about that inheritance are worth stating. First, SerenityOS is an operating system, not a browser, so these libraries were written to a different product's requirements and are being adopted rather than designed for this one. Second, the qualifier is not decorative: at the moment, many components are inherited. That is a statement about an ongoing state, not a settled fact, and it means the boundary between inherited and Ladybird-specific code is still moving.

For a reader this cuts both ways. Inheriting a decade of engine work is why the project has a rendering engine at all, and it is the single clearest reason a from-scratch browser is achievable at all. It is also why a bug in LibWeb may be a SerenityOS bug that upstream will not prioritise for a browser, and why an issue you file here may not be fixable here. Anyone planning to contribute should read the inheritance list as a map of where the risk is.

One renderer process per tab, with decoding and networking pushed out of process

The process architecture is the part of the design that a security-minded reader will care about, and it is stated in three sentences. Ladybird uses a multi-process architecture with a main UI process, several WebContent renderer processes, an ImageDecoder process, and a RequestServer process. Image decoding and network connections are done out of process to be more robust against malicious content. Each tab has its own renderer process, which is sandboxed from the rest of the system.

Read that as a threat model. The renderer is where untrusted content is interpreted, so giving every tab its own renderer means a crash or an exploit in one page takes down that page rather than the browser, and the sandbox means the renderer does not have the authority to reach the rest of the machine. Moving image decoding out of the renderer is the sharper decision: image decoders are a classic source of memory-safety bugs, and putting them behind a process boundary means a malformed image takes out the decoder rather than the tab.

The RequestServer follows the same logic from the other direction, isolating the network stack from page content so that a request cannot be made to look like something the page did not ask for. None of this is a claim about how well the sandbox is implemented, and the README says nothing about the sandbox's mechanism. What it does is commit to a shape, and a shape is what you can hold the project to as the implementation matures.

The named library list stops at an HTTP/1.1 client

Of the ten libraries in the list, nine name a capability without qualification. LibWeb renders, LibJS runs JavaScript, LibWasm runs WebAssembly, LibCrypto and LibTLS handle cryptography and transport security, LibGfx draws in 2D and decodes images, LibUnicode handles text and locale, LibMedia plays audio and video, LibCore runs the event loop, and LibIPC moves messages between processes.

LibHTTP is the exception, and it is qualified as an HTTP/1.1 client. Read strictly, that is all the list claims, and the list does not name an HTTP/2 or HTTP/3 implementation anywhere. The web today is substantially HTTP/2, and a great deal of site behaviour depends on it, so a reader assessing this browser for real use has a question the README does not answer, and it has to be answered from the source or from the issue tracker.

That is a gap in a list rather than a defect in the code, and lists compress. But it is the kind of omission that matters: the list is the only place a newcomer sees the scope of the platform, and a named omission in it is more informative than a missing entry, because it tells you the HTTP layer is where the work is. The same test applies to the rest of the list. Every entry is a category rather than a conformance level, and no entry tells you how complete it is.

Building it means CMake, Cargo, vcpkg, Ruff and Pyright in the same checkout

The repository root is a better description of the engineering than the README is. C++ tooling is everywhere: .clang-format, .clang-tidy, .clangd, .gdbinit, .lldbinit and a YCM configuration file, plus CMakeLists.txt, CMakePresets.json, and a vcpkg.json with its own vcpkg-configuration.json for dependency management.

Alongside that sits a Rust workspace. Cargo.toml declares fourteen members, and they are the same libraries as the C++ list seen from a different angle: AK/Rust, and Rust directories under LibCompositing, LibGfx, LibImageDecoders, LibJS, LibRegex, LibTextCodec, LibUnicode, LibURL, LibWasm, LibWeb including its content blocker and its HTML parser. One member is excluded, LibJS/Flap. There is a rust-toolchain.toml and a rustfmt.toml, so the Rust version is pinned by the repository rather than by your machine.

Then there is Python. pyproject.toml configures Ruff with a line length of 120, a target version of py39, flake8-bugbear and isort selected, and isort forced to single-line imports. The same file configures Pyright at Python 3.9 with extra paths pointing into the web platform test harness, Tests/LibWeb/Text/input/wpt-import and its tools, and an exclude list that skips node_modules, caches and dotfiles. A devcontainer configuration sits alongside. Five toolchains in one checkout is the real cost of this project, and none of it is mentioned in the 282-word README, which sends you to Documentation instead.

WebCompat/ sits at the root next to a standalone iframe reproduction page

Two entries at the repository root describe where the actual work is. There is a WebCompat directory, which is the web compatibility effort, and next to it a single file called iframe-transform-repro.html, which is a minimal reproduction of one specific problem rather than a test harness or a demo page. Shipping a one-file repro at the root tells you the project treats a failing site as a bug report with an attachment.

The other top-level directories follow the architecture rather than the feature list. AK and Base are the kernel and userland base, Libraries holds the named components, Services holds the ImageDecoder and RequestServer processes, UI holds the browser chrome, Meta holds build and packaging scripts, Utilities holds command-line tools, WebCompat holds the compatibility work, and Tests holds the test suites including the LibWeb text input tests that the Pyright configuration reaches into.

Contributing is gated in four documented steps rather than left implicit. There is a Discord server for issue and development discussion, a Getting involved with Ladybird document for newcomers, an issue policy section inside CONTRIBUTING.md, and a separate ISSUES.md with detailed issue-reporting guidelines that the README asks you to read before opening anything. Four documents before your first issue is friction, and for a project that is pre-alpha and developer-only it is the right friction: the alternative is a queue of environment questions answered one at a time.

Editorial conclusion

Ladybird suits an engineer who wants to see what a browser looks like with no engine fork underneath it, and the architecture is genuinely worth reading: one renderer process per tab, image decoding and networking out of process, and every core library named in the README. It does not suit anyone who needs a browser this week, since the project describes itself as pre-alpha and developer-only, and it does not suit a Windows user who wants a native build, since the supported path is WSL2. Before you build it, read the build instructions document rather than the README, because the README is 282 words and the four-toolchain setup lives entirely in Documentation, and check your Rust, CMake and vcpkg versions against that document before you start, because the workspace denies a long list of clippy lints and an older toolchain will not pass.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository