There is a number almost nobody knows, though it affects everyone: three. Three browser engines render nearly the entire World Wide Web. Blink, developed by Google. Gecko, developed by Mozilla. WebKit, developed by Apple. Everything you see in a browser — every webpage, every application, every online shop, every banking session, every video conference — is brought to screen by one of these three engines.

Three companies. One market controlling the digital world.

And now someone comes along and builds a fourth. From scratch. Without adopting code from any existing engine. No fork. No user monetization. Funded by donations, backed by a non-profit organisation. The name: Ladybird.

That isn’t simply a new product. It’s an act of refusal.

Why the browser is the most important program

The browser is the most frequently used application on almost every device. It is door, window and bridge simultaneously. Through it we reach government agencies, banks, schools, doctors, friends, employers. It has partly replaced the operating system — many people barely need a local program besides the browser.

Whoever controls the browser controls access to the digital world. And whoever controls the browser engine controls the browser.

A browser engine is the heart: it parses HTML, interprets CSS, executes JavaScript, lays out the page, renders pixels onto the screen. It decides how a webpage looks, how fast it loads, whether it works at all. It determines which web standards are supported and which are not. It is the authority translating between a webpage’s code and what the user sees.

Three authorities. Three translators. Three interpretations of the same standard.

A thin market that grew thinner

It wasn’t always thus. In the nineties there were dozens of browser engines. Netscape Navigator, Internet Explorer, Opera with Presto, KDE’s KHTML, Mozilla’s early Gecko, Amaya, Mosaic — each with strengths, weaknesses, opinions of its own about how the web should work.

Then consolidation arrived. Internet Explorer conquered the market and nearly suffocated the competition altogether. Mozilla fought back with Firefox. Apple split off KHTML and created WebKit. Google took WebKit, split it again and created Blink. Opera abandoned Presto and moved to Blink. Microsoft abandoned EdgeHTML and likewise switched to Blink. KHTML, Trident, Presto, EdgeHTML — all gone.

Three remained.

Goanna, a Gecko fork surviving in Pale Moon, is a niche project. Servo, an experimental Mozilla project, exists but isn’t production-ready. NetSurf exists but is extremely limited. Flow exists but is commercial and closed. The reality is: whoever browses the web today uses Blink, Gecko or WebKit. Period.

What monoculture means

Monoculture sounds agricultural, but in IT the term is precise. When everybody uses the same engine, everybody is vulnerable to the same bug. A security hole in Blink affects Chrome, Edge, Opera, Brave, Vivaldi, Arc — roughly seventy percent of the market. A rendering bug in WebKit affects every Safari user, every iOS user (because on iOS WebKit is the sole permitted engine), everyone using GNOME Web.

But the security argument is only the obvious one. The deeper problem is the question of power.

Whoever controls the dominant engine controls the web standards de facto. With Blink, Google holds the power to steer the web in a direction serving its own business interests — more surfing time, more ad revenue, more data collection, more dependence on Google services. Standards Google finds inconvenient get delayed. Features benefiting Google get shipped before they’re standardised. That isn’t conspiracy theory. It’s the ordinary dynamic of a quasi-monopoly.

Mozilla carries a voice with Gecko, but a quiet one. Apple carries a voice with WebKit, but one tied primarily to its own platform. Whoever uses WebKit uses it because Apple mandates it — not because they chose it.

A fourth engine means a fourth voice. A fourth opinion about how the web should work. A fourth implementation of the same standard, catching errors the others overlooked. A fourth authority owing nothing to the incumbents.

Ladybird: not a fork, but a fresh start

Here Ladybird gets interesting. And here precision matters.

Many projects calling themselves “alternatives” aren’t. Brave uses Blink. Vivaldi uses Blink. Arc uses Blink. They may sport different interfaces, different philosophies, different privacy promises — but beneath the bonnet runs the same motor as Chrome. If Blink has a bug, they all have it. If Google changes an API, they all follow.

Ladybird is different. It isn’t a new skin over a borrowed motor. It’s an original motor, built from the ground up. The rendering engine is called LibWeb. The JavaScript engine is called LibJS. Both were written from zero — no code from Blink, Gecko or WebKit. That’s a statement whose radicality has grown rare in this industry.

Andreas Kling, the founder, began the project in 2019 as part of SerenityOS, a hobby operating system with a culture of radical from-scratch writing. In 2022 Ladybird became independent. In 2024 Kling founded the Ladybird Browser Initiative, a 501(c)(3) non-profit organisation. Funding comes exclusively from donations and sponsoring — Cloudflare, Shopify, FUTO, 37signals, Proton VPN, the Human Rights Foundation are among the backers.

No search engine deals. No crypto tokens. No data collection. No advertising. No avenue for an investor to sway the technical roadmap. That’s stated on the website, and it’s anchored in the organisational structure: sponsorships are pure donations. Board seats are not for sale. Technical direction is set by the engineers, not by the financiers.

Where Ladybird stands

Ladybird isn’t finished. That should be said plainly. The alpha release is slated for 2026, initially for Linux and macOS. A beta is expected in 2027, a stable release in 2028. Whoever builds it today can load websites — but it isn’t a browser for everyday use. It’s a browser for developers, testers and the curious.

What impresses, though: Ladybird already ranks fourth on the Web Platform Tests — behind Chrome, Safari and Firefox. The JavaScript engine, LibJS, is the second-most conformant after SpiderMonkey (Firefox). For a project begun from scratch, at a scale carried by a small full-time team, that’s remarkable.

The codebase originated in C++ but is being ported to Rust incrementally — subsystem by subsystem. That isn’t cosmetic. Rust eliminates whole classes of memory-safety bugs chronic in C++. A browser engine in Rust is structurally safer than what the competition operates. That Ladybird walks this path says something about its ambition.

Why diversity is a question of sovereignty

So far this has been about technology. Now it’s about politics — not partisan politics, but in the sense of power and dependence.

The web is the universal platform. Whoever controls it controls access to digital society. When three corporations decide which web standards exist, which features ship, how privacy is handled, which APIs are admitted and which aren’t — then the web isn’t free. It’s administered.

Sovereignty in the digital space means not depending on the grace of individual conglomerates. It means the tools we use are comprehensible, auditable and controllable. It means standards are open and multiple independent implementations exist that can cross-check each other.

A fourth engine is a contribution to that sovereignty. It breaks the quasi-monopoly. It forces the others to justify themselves when they deviate from the standard. It offers a reference implementation against which the others can be measured. It is a laboratory for ideas that needn’t align with the business models of giants.

And it’s open. Ladybird is released under a BSD licence. The code sits on GitHub. Anyone can read it, audit it, understand it. Anyone can trace what the engine does — unlike closed engines, where you hope they do what they claim.

Why you should take a look at Ladybird

Anyone interested in open software, in sovereignty, in the notion that the web should belong to nobody, should have Ladybird on their watchlist. Not because it’s a finished browser today — it isn’t. But because it’s a project posing a question too seldom asked: do we really need only three motors to render the whole world?

You can support the project. Through donations via Donorbox, through sponsoring, through testing, through bug reports, through technical contributions. The website ladybird.dev explains how. Every contribution helps — the project is financed entirely by donations, and every dollar goes into the engine, not into marketing departments or shareholder value.

You can also simply observe it. Read the monthly newsletter. Watch what happens. Because even those who never use Ladybird benefit from its existence. A project proving a new engine is possible raises pressure on the incumbents. It demonstrates the web needn’t be reduced to three actors. And it keeps the discussion alive about whom the web belongs to.

What this means for libcom.de

Browser engines are infrastructure. And infrastructure is what libcom.de does — plan, build, operate, understand. Not every operation needs its own browser engine. But every operation should grasp which engine its users employ, what dependencies that creates, and what risks ensue.

Running IT where browsers are central — and which operation doesn’t today — you should know that your enterprise’s entire web presence is rendered by three engines controlled by three companies. That’s a risk. Not an acute one, not one striking tomorrow. But a structural one. And structural risks are the easiest to overlook and the hardest to correct.

If you wonder how your IT is affected by such dependencies, which alternatives make sense, or how to gain more sovereignty over your infrastructure: write to contact@libcom.de. We take an honest inventory. Without sales pressure. With a view to what lasts long-term.


The web belongs to nobody. That was the idea. Three motors are too few to sustain it. A fourth is a beginning.