Ladybird: A Pre-Alpha Browser Built on SerenityOS Libraries, Not a Fork
Ladybird is an independent browser built on its own standards-based engine, with a multi-process architecture and sandboxed tabs; currently pre-alpha for developers.
At a glance
- What is it?
- Ladybird is a multi-process browser with its own engine, currently pre-alpha and aimed at developers. It reuses SerenityOS components like LibWeb and LibJS, which shapes both its strengths and its limits.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Ladybird Actually Is
The core problem Ladybird solves is the near-total dominance of a few rendering engines. By building an independent engine, it provides a testbed for web standards that is not tied to the priorities of Google, Mozilla, or Apple. 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 top of a decade of SerenityOS development. 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. That is a significant limitation for modern web browsing. Many sites require HTTP/2 for performance, and some features like server push or multiplexing are absent. For a developer testing a browser engine, this is acceptable, but it means Ladybird will not render many real-world sites correctly or efficiently. 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 a clean-room 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 only viable open-source option in this space. 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. There are no recent releases listed in the repository data. 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.
Community notes