Ladybird Wants to Be the Browser Engine Nobody Owns

Every few years somebody announces a new browser engine. Almost every time, the announcement turns out to be the most interesting thing that ever happens to the project. The repo gets some stars, a blog post gets written, and then nothing.

Ladybird is the exception, mostly because it kept going long enough that it stopped being a hypothetical.

This is a project I keep coming back to, and not for the reasons I expected. I reached for it as “interesting browser.” What I found instead was a much better story about process isolation, privilege separation, and how a governance decision cost a year of schedule.

Where it came from

Ladybird started in 2019 as a component inside SerenityOS, Andreas Kling’s from-scratch, retro-inspired operating system. Kling started SerenityOS in 2018; by most accounts the project began partly as a way to get himself through a drug recovery program, which is a strange and rather moving origin for what became a serious browser engineering effort.

SerenityOS is a monorepo, meaning every subsystem lives in one tree. That structure is why Ladybird exists in a slightly unusual form: LibWeb (the rendering engine) and LibJS (the JavaScript engine) are libraries that SerenityOS uses and Ladybird embeds. The browser is the part that was factored out.

Some of the important context: BSD 2-Clause licensed, no company behind it, and no user monetization and no sponsors with strings attached. That last part defines everything else.

What it explicitly is not

From the project’s own FAQ, the three things it is not:

• Not a Chromium/Blink shell
• Not a WebKit port
• Not a Firefox fork

This matters more than it sounds. Almost every “new browser” you’re offered in 2026 is one of those three wearing a new interface. Ladybird is a genuinely independent implementation of the web platform standards, which is an enormous amount of work: the web platform is not small, and nothing about it is well specified.

The 2026 timeline, from their own newsletters

I went through the project’s monthly write-ups, and the progress is more real than the “pre-alpha, developers only” warning suggests:

• January: They fix something that tells you a lot about the state of the web. Many sites check User-Agent and, seeing a browser they don’t recognize, serve degraded layouts, throttle the connection, or return a flat HTTP 403. Ladybird’s fix was to add "Chrome/140.0.0.0" and "AppleWebKit/537.36 Safari/537.36" to its UA string, keeping Ladybird in there too. In other words: to make the web work, they had to tell it they were someone else.
• May: 464 pull requests merged in a single month. Clears Cloudflare Turnstile. Scrolling moves onto an out-of-process compositor.
• June: Downloads, browsable history, cookie/storage inspection in DevTools, video playback speed. And the big one: services start running inside real security sandboxes on Linux and macOS.
• July: Private browsing, browser profiles, undo/redo, geolocation, working WebAudio. The style system and layout engine move to Rust.
• August: Twitch video playback, more YouTube formats, CSS scroll snap, JS debugging in DevTools, resumable downloads, session restore. New style engine, layout caching, CSS animations off the main thread, occlusion culling.

That August list is not a demo. Occluding hidden windows so they stop rasterizing and stop scheduling frames is the kind of work that only matters if you actually intend to run a browser for hours at a time.

The sandboxing, which is the part I’d actually deploy

Here’s where my brain went, and it’s the part I care about most.

Ladybird uses a multi-process architecture where each tab gets its own WebContent process, handling HTML parsing, CSS, JavaScript, and paint. And as of June 2026, every process except the main browser runs under a real OS-level sandbox, not an internal discipline but an actual kernel-enforced one.

On Linux that’s Landlock and seccomp. The code is worth a look if you enjoy this sort of thing; the Linux renderer sandbox does the unglamorous work you’d expect:

install_no_new_privileges()
configure_runtime()
add_landlock_path_if_exists(resource_root, ReadOnly)

There’s a LibSandbox layer that builds those policies per service, applied separately to ImageDecoder, Compositor, RequestServer, WebContent, and WebWorker. WebContent and WebWorker share a policy for now.

And then there’s the detail I like most: the PR that made helper sandboxing on by default, replacing an --enable-sandbox flag with --disable-sandbox. Defaulting to unprotected and letting operators opt in is a common way to end up unprotected. Ladybird flipped it. You now have to explicitly ask for the insecure version.

If you run infrastructure, you already have this mental model. Privilege separation, least privilege, unprivileged helper processes, per-service policy. Ladybird is applying datacenter service design to a document renderer that executes attacker-controlled code by design. That’s the correct instinct, and it’s the reason I’d take this project seriously even if I never opened it.

The part that’s a mess: the Rust pivot

In February 2026 the project announced it was adopting Rust, in a blog post titled, more or less, “Ladybird adopts Rust, with help from AI.”

According to The Register, they also attributed a delay of roughly a year in development to the effort. The work described involved ditching Swift and translating a large body of C++ with assistance from LLM-based coding tools. By July, the style system and layout engine had moved to Rust.

I want to be careful about how I characterize this, because the headlines have been less than charitable and I don’t think the charitable reading is wrong but I also can’t verify the internals.

Here’s my honest read as an infrastructure person.

The good: an engine is a codebase you cannot safely rewrite casually, and modern C++ is not the best substrate for the kind of memory-safety work a browser engine exists to get right. Rust makes entire bug classes unrepresentable. If you’re going to invest in language migration, this is a defensible reason.

The bad: a mechanical, LLM-assisted translation of a codebase at your project’s core is not the same activity as porting a well-tested module. It is not obviously faster, and it is certainly not obviously cheaper, because the cost lands later as “subtle behavioral differences nobody noticed for four months.” And notably, the sandboxing work shipped in the same period, so the migration did not slow everything down uniformly, it slowed some things down while other things accelerated.

The thing that actually matters: the migration did not stop the project. That’s the whole test. Plenty of projects announce a rewrite and then stop existing. This one had 464 PRs in May and shipped real sandboxing in June, in the middle of it.

What you can actually do with it in 2026

Here’s the honest state, because this is where most coverage gets vague.

From the project itself: pre-alpha, suitable for developers. The roadmap is:

So there’s no package to install. The FAQ is unambiguous about why: the only way to really know how your specific sites behave is to follow the build instructions, build it from source, and try it.

Platform support:

• Linux: native, and where the sandboxing work is deepest
• macOS: native, sandboxing landed here in June too
• Windows: WSL2 only. The FAQ is direct about why: very few Windows developers contribute, a native port would distract from web platform standards, and it is not a priority. (There were hints in mid-2026 that an internal native Windows build exists, but nothing you can rely on.)
• Android: experimental

If you want to try it

On Linux, the interesting version is the sandboxed one:

# Requires a recent Clang, CMake, Ninja, and the usual build deps.
# The sandbox path needs Landlock and seccomp available on your kernel.
git clone https://github.com/LadybirdBrowser/ladybird
cd ladybird
./Build.sh --release

# Then run it and watch it fail to load something:
# that failure is the actual current state of the project.
./Build/release/ladybird

Expect to break on real sites. That’s not a bug in your setup; that’s the project, and the project says so itself. The January UA story is the honest summary: a large fraction of the web actively refuses to render in a browser that admits what it is.

What I’d tell you

Ladybird is worth watching for two reasons, and they’re not the reasons it’s usually discussed.

First, it is the only credible attempt in a long time at an engine that nobody owns. Not independently governed by a foundation that still has a browser monoculture incentive, not owned by a company that needs you to buy something. A 501(c)(3), no monetization, no sponsors with strings. That’s a small but real structural advantage over the alternative of hoping a new browser exists that isn’t run by a business model you dislike.

Second, the Rust migration is a genuinely useful case study in what happens when you rewrite the thing that holds all the risk. Not because it went badly (there’s real evidence it went reasonably), but because they were willing to say out loud, in the title, that AI was involved, and then kept shipping. Most projects doing a migration that expensive would have either quietly abandoned it or quietly never mentioned why.

The uncomfortable thing about Ladybird is that it also illustrates how much of the modern web has quietly become hostile to browsers that don’t lie about what they are. The engines are gone, and what’s left is a web that mostly serves Blink, Gecko, or WebKit, and degrades everyone else. Ladybird’s answer was to lie back. That it took that as the highest-value fix it could make is a commentary on the web we’re stuck with.

That might be the real story of this project. The browser engine work is the fascinating part, but the reason it matters is what it documents: the web stopped being a platform with a specification and became a negotiation with three companies.

---

Sources: ladybird.org and the project’s monthly newsletters for January, May, June, July, and August 2026; the project FAQ and process-architecture documentation on GitHub; the Linux renderer sandbox implementation and the Linux sandboxing PRs (#10001, #10132); The Register, February 2026; Wikipedia for the SerenityOS origin story.