Ladybird: A Pre-Alpha Browser Built on SerenityOS Libraries

What Ladybird Actually Is

The README describes Ladybird as a truly independent web browser using a novel engine based on web standards. The intended audience is developers who want to contribute to a browser project or study how rendering, JavaScript, and networking fit together. The README invites participation through Discord and a contributor guide, so the project is explicitly open to outside help.

Multi-Process Architecture and Out-of-Process Components

Ladybird uses a multi-process architecture. There is a main UI process, several WebContent renderer processes, an ImageDecoder process, and a RequestServer process. Each tab gets its own renderer process, which is sandboxed from the rest of the system. Image decoding and network connections run out of process. The stated goal is to be more robust against malicious content. This is a sensible design: isolating image parsing and network I/O reduces the blast radius of a vulnerability in those components. The renderer sandboxing is also a standard defense, though the README does not specify the sandboxing mechanism. A developer will want to check the source for details on how the sandbox is implemented on each platform, because that is where real-world security claims are won or lost.

The SerenityOS Library Heritage

The README lists several core libraries inherited from SerenityOS. These include LibWeb for rendering, LibJS for JavaScript, LibWasm for WebAssembly, LibCrypto and LibTLS for cryptography and TLS, LibHTTP for HTTP/1.1, LibGfx for graphics and image decoding, LibUnicode for locale support, LibMedia for audio and video, LibCore for the event loop, and LibIPC for inter-process communication. This is a substantial foundation. It means Ladybird is not starting from zero; it is building a browser on libraries inherited from SerenityOS. The trade-off is that these libraries were designed for a specific operating system, SerenityOS, and adapting them to Linux or macOS may carry assumptions that do not hold everywhere. The README does not discuss portability issues, but any engineer should expect friction when moving OS-specific code to a new platform.

Building and Running: What the README Tells You

The README points to Documentation/BuildInstructionsLadybird.md for build instructions. It does not include the commands in the README itself. That is a gap. A developer will have to open that file to see the actual steps. The README does state that Ladybird runs on Linux, macOS, Windows with WSL2, and many other Unix-like systems. It does not list dependencies, build flags, or a sample build command. For a pre-alpha project, this is a common pattern: the documentation is a work in progress. If you want to try it, the first step is to read that build document and verify that your environment matches. Do not expect a package manager install or a prebuilt binary, because the README mentions none.

A Real Limitation: HTTP/1.1 Only and Pre-Alpha Stability

The README lists LibHTTP as an HTTP/1.1 client. There is no mention of HTTP/2 or HTTP/3. The README does not say whether other components handle newer protocols, so do not assume support for them. The pre-alpha warning reinforces this: the engine is incomplete. The README does not list specific missing features, so you cannot know what will break. That uncertainty is a genuine failure mode. If you plan to use Ladybird for anything beyond basic testing, you will hit walls.

The Alternative: Forking an Existing Engine or Using a Headless Browser

The obvious alternative to Ladybird is to build on an existing engine like Chromium or WebKit. Projects like Electron or Qt WebEngine take that route. The difference is approach: Ladybird is described as an independent engine, whereas those alternatives reuse mature code with decades of security fixes. If your goal is a custom browser with minimal effort, forking Chromium gives you a working product quickly. If your goal is to understand or advance browser technology independently, Ladybird is the one to look at. Another alternative is to use a headless browser like Playwright or Puppeteer for testing, which does not involve building a browser at all. The choice depends on your intent: production use versus research.

Maintenance, Upgrades, and License

The README does not mention a release cadence, versioning, or a changelog. The repository has no GitHub releases. That suggests the project is in continuous development without stable milestones. For an adopter, that means you cannot rely on a stable API or predictable upgrades. You will be tracking the master branch, which is a moving target. The license is BSD-2-Clause, which is permissive. You can use the code in commercial projects with attribution. However, the README does not discuss patent grants or contributor license agreements. That is a legal detail you would need to verify separately. The maintenance cost is high: you must build from source, follow the master branch, and likely fix build breaks yourself. This is not a drop-in component; it is a research project.

Editorial conclusion

Adopt Ladybird if you are a developer who wants to experiment with a genuinely independent browser engine and can tolerate instability and missing features. Do not use it for daily browsing or any production task. Before you invest time, verify that the build instructions in Documentation/BuildInstructionsLadybird.md match your OS, that you can meet the dependency requirements, and that you are comfortable with the pre-alpha warning. The project is BSD-2-Clause licensed, so code reuse is permissive, but the engine is not yet a viable alternative to mainstream browsers.

Frequently asked questions

Official sources

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