The Gateway to the Web, the Internet

In a world dominated by a handful of tech giants, building a new web browser from scratch is an act akin to challenging the gods.

Yet, this is precisely what the Ladybird browser project is doing. It is not simply putting a new skin on existing technology; it is dedicated to creating a truly independent web browser, with a brand-new engine (LibWeb) and a self-developed JavaScript interpreter (LibJS) at its core.

So, in today’s article, we will discuss what a browser engine truly is and why they are not as numerous as scattered blossoms from a celestial maiden. And, what would happen if Chrome were to be acquired?

Of course, I am a Safari and Firefox enthusiast; Chrome is merely a subject for discussion.

The Heart#

To most users, a browser is just an icon on the screen, a gateway to the vast internet.

But behind this gate, the core component at work is a complex piece of software known as the Browser Engine. We can understand it through a few simple analogies.

It is the heart of the browser, tirelessly pumping data. It is also a great translator, taking the raw code of websites—the text composed of HTML, CSS, and JavaScript that is difficult for humans to read directly—and translating it in real-time into the interactive, rich, and vivid web pages we see on our screens.

The terms Browser Engine, Layout Engine, and Rendering Engine are often used interchangeably.

Together, they describe the core part of the browser whose primary responsibility is to interpret web page code, calculate the position and style of every element on the page (i.e., “layout”), and then draw them onto the screen.

To understand the structure of a browser more clearly, we need to distinguish the browser engine from two other parts: first, the User Interface (UI), which includes the address bar, forward/back buttons, tabs, etc., that we can see directly.

Second is the JavaScript Engine, a separate component specifically responsible for executing the JavaScript code within a web page, endowing the page with dynamic interactivity.

The browser engine coordinates all of this, working closely with the JavaScript engine to transform a static document into a living application.

History#

Looking across the modern internet, nearly all web experiences are driven by three major browser engine families.

They are the product of technological evolution and market competition, each representing a unique evolutionary path:

• Blink: Developed under Google’s leadership, forked from the WebKit project in 2013. It is the engine with the highest market share in the world today, powering Chrome, Microsoft’s Edge, Opera, Brave, Vivaldi, and many other browsers.
• WebKit: Developed under Apple’s leadership, its history can be traced back to the even earlier KHTML engine. WebKit is the core of the Safari browser. Before Blink’s creation, it was also the engine for the Chrome browser.
• Gecko: Developed by the Mozilla Foundation, it is the core of the Firefox browser. Outside the Blink/WebKit ecosystem, Gecko is currently the only independent engine that still maintains a significant market share and influence.

Furthermore, we should not forget the participants of the past, such as Microsoft’s Trident (used in Internet Explorer) and EdgeHTML (used in the legacy version of the Edge browser).

(The Blink engine is part of the Chromium open-source project)

The Miracle#

Entering a URL#

It all begins with a simple action: typing a web address (URL) into the address bar and pressing Enter.

Upon receiving this command, the browser’s built-in networking component immediately gets to work.

This process can be roughly divided into several steps:

1. DNS Lookup: The browser first needs to know the location of the server corresponding to this web address. It queries the “Domain Name System” (DNS), which acts like the internet’s “phone book,” translating human-readable domain names (like www.baidu.com ↗) into IP addresses that servers can understand (like 220.181.7.203).
2. Establishing a Connection: After obtaining the IP address, the browser establishes a reliable connection with the target server via the TCP protocol.
3. Sending a Request: Once the connection is established, the browser sends an HTTP request on behalf of the user to the server, requesting the content of the web page corresponding to the URL.

DOM and CSSOM#

After the server receives the request, it returns the corresponding data, typically starting with an HTML file.

At this point, the rendering engine begins Parsing.

First, the engine reads the HTML code line by line and converts it into a tree-like logical structure that a computer can understand, known as the Document Object Model (DOM).

This process is like converting an architect’s blueprint into a structured list containing all rooms, walls, doors, and windows and their relationships.

Second, while parsing the HTML, the browser also requests and parses the CSS files referenced in the HTML. It converts all the style rules (such as colors, font sizes, layout methods) into a tree structure as well, called the CSS Object Model (CSSOM).

Render Tree#

Next, the engine combines the DOM tree and the CSSOM tree to create a new tree, the Render Tree.

This tree is the master plan for the final visual presentation of the page. It is very intelligent, containing only those elements that actually need to be displayed on the screen.

For example, an element set to display: none in CSS will not appear in the render tree. Every node in the render tree contains its final style information.

Everything in its Place#

Once the render tree is built, the process enters a crucial step: Layout, sometimes also called Reflow.

In this phase, the engine precisely calculates the geometric information of every node in the render tree on the screen—that is, its size and position.

From the width of the entire page to the height of a button, to where a line of text should wrap, all these spatial relationships are calculated with pixel-perfect precision in this step.

Painting#

When the position and size of all elements have been determined, the engine can finally begin Painting.

It will traverse the render tree and call the operating system’s graphics API (UI backend) to draw every element—text, images, background colors, borders, etc.—onto the corresponding pixels of the screen.

It is worth noting that this entire process is progressive. To provide a better user experience, the browser will start drawing content as early as possible, rather than waiting for all HTML, CSS, and images to be downloaded.

This is why we sometimes see the page content appear first, and then the styles load in, causing the page to flicker for a moment (i.e., Flash of Unstyled Content).

Interactivity#

After the page is initially drawn, the separate JavaScript engine (for example, the V8 engine in Chromium) begins to shine.

It is responsible for executing the JavaScript code embedded in the page, breathing life into the otherwise static page.

Whether it’s a pop-up window after clicking a button, smooth scrolling animations on the page, or loading new content without refreshing the page (AJAX), it’s all thanks to JavaScript.

This process also reveals a key aspect of performance optimization. All these operations—from layout and painting to JavaScript execution—typically occur on the same main thread.

If a piece of JavaScript code takes too long to execute, it will block the main thread, preventing the browser from responding to user actions like scrolling or clicking. The page will then appear to freeze or stutter, even if the content the user sees has fully loaded.

This is precisely why browser developers continuously invest immense effort in performance optimization.

Google vs. The US#

Since we’re on the topic of Chrome, let’s briefly touch upon the antitrust issue. In short, Federal Judge Amit Mehta ruled in August 2024 that Google illegally maintained its monopoly in the general search services and search advertising markets.

For example, Google paid a staggering $26.3 billion in 2021 alone to ensure its search engine was the default option on various platforms.

Following this verdict, the Department of Justice (DOJ) proposed a series of remedies aimed at dismantling this monopoly, with the most striking core demand being the forced divestiture of Google’s Chrome browser business.

As the browser with an absolute leading market share, Chrome is a critical tool for Google to maintain its search monopoly. It is not only the most important distribution channel to reach billions of users but also a massive data collection terminal, further solidifying Google’s moat in the search domain.

(Note, the DOJ’s divestiture order targets Google Chrome)

Public Works#

So the question arises: after being forced to sell its flagship browser product, would Google still have the motivation to continue its huge investment in the Chromium project?

The answer is yes, because Google’s core business interests are inextricably linked to the health of the open web.

Google’s main revenue streams—search advertising, YouTube, and Google Cloud services—all rely on a fast, stable, secure, and constantly innovating web platform.

A stagnant or fragmented web would directly harm Google’s ability to monetize content and services.

Therefore, funding Chromium is not just about supporting a browser product; it is about maintaining the foundational infrastructure of its multi-trillion-dollar ecosystem.

At the same time, Google can continue to guide web standards, ensuring the web platform evolves in a direction favorable to its advanced advertising technologies, rich media content, and complex web applications.

Of course, another of Google’s goals is to prevent competitors like Apple (with its WebKit engine) from dominating the development direction of web standards, thus avoiding a situation where its core services are disadvantaged in the future web environment.

Therefore, Chromium can be seen as a strategic moat for Google, rather than merely a dependency of one of its products.

The DOJ’s remedies aim to dismantle Chrome as a product used to fortify the search monopoly, but Google’s business model itself depends on the health of the entire open web platform.

The key force shaping this platform is Chromium’s Blink engine. Thus, even if it loses the Chrome product, Google’s motivation to influence the web platform’s evolution by investing in Chromium remains.

This is no longer for a divested product but a strategic investment to protect its core revenue streams from platform-level risks (e.g., the web’s evolution being dominated by Apple, or becoming too fragmented to monetize effectively).

Funding Chromium is the public works overhead that Google must bear to maintain the foundations of its business empire.

So, does divesting Chrome really solve the monopoly?

Maintenance Costs#

Maintaining Chrome and its underlying Chromium project is an engineering effort of immense scale, with costs and complexity comparable to developing an entire operating system.

Here, we’ll temporarily skip the development issues of Chromium, saving them for when we discuss Ladybird later. Let’s first talk about Chrome’s security issues.

Security assurance relies on rapid response. Chrome releases a full browser update approximately every 4 to 6 weeks, while minor updates containing critical security fixes are released every 2 to 3 weeks.

Nearly every update contains security patches, and all patches should be considered equally important. This high-intensity update cadence requires a large, professional security and release engineering team.

In other words, potential buyers of Chrome like OpenAI and Perplexity, despite valuations in the tens or even hundreds of billions of dollars, are themselves burning through billions in cash for their core AI businesses.

These companies’ core competency lies in large language models, not in managing a global security infrastructure for a client application with billions of endpoints.

Therefore, the security burden itself becomes a huge, non-obvious barrier. The acquirer buys not just a massive user base, but also inherits a perpetual war on the network front.

This severely limits the pool of qualified candidates and even casts doubt on the feasibility of the divestiture plan itself.

(Chromium is an indirect beneficiary of all security rewards and investments Google pours into Chrome)

---

Furthermore, the DOJ’s goal is to “free the market from anticompetitive conduct and restore competition.” The harm identified by the court is Google’s use of its dominant asset (Chrome) to protect another dominant asset (Search).

However, selling Chrome to a well-funded entity like OpenAI would likely not solve the fundamental antitrust problem, but merely transfer it to the next technological paradigm.

An OpenAI acquisition of Chrome would perfectly replicate Google’s model: leveraging a market-dominant asset (Chrome) to solidify its leading position in the emerging and potentially more critical market of AI agents and AI-driven information retrieval.

This creates a monopoly paradox: the remedy taken to solve one monopoly directly sows the seeds for the formation of the next. Regulators may just be solving yesterday’s problem while creating tomorrow’s.

Because any competitor possessing Chrome’s market power could easily make its AI service the default entry point to the internet, which runs counter to the original intent of breaking up Google and fails to address the substantive issue of monopoly.

The Foundation#

Faced with the various drawbacks of a corporate sale, a more constructive alternative emerges: placing the Chromium project under the governance of a neutral, non-profit foundation.

This approach is widely considered the best way to ensure the continued healthy and neutral development of Chromium as a critical piece of web infrastructure.

The foundation’s operation could emulate successful open-source organizations like the Linux Foundation or the Apache Software Foundation.

Governance would be shared among major stakeholders who depend on the Chromium ecosystem, including Google, Microsoft, Opera, and others.

The foundation’s operational funds would be provided jointly by a consortium of members who rely on the ecosystem. This model distributes the financial burden and effectively prevents any single company from exerting undue influence.

---

The above is just a brief commentary on a current topic; the main purpose of this article is to introduce Ladybird.

Ladybird#

Ladybird’s origins can be traced back to the SerenityOS project, a hobbyist desktop operating system built entirely from scratch.

Initially, Ladybird was merely a simple HTML viewer within that system. This history is crucial to its subsequent development, as it established the project’s culture of first principles—that is, building the system by directly implementing foundational specifications rather than relying on existing frameworks.

A key turning point for the project was the decision by its founder, Andreas Kling, to step back from the daily maintenance of SerenityOS to devote his full attention to the development of Ladybird, forking it from SerenityOS to become an independent, cross-platform project.

To ensure the project’s long-term independence and mission-driven nature, the team officially established the Ladybird Browser Initiative, a non-profit organization registered in the United States.

This organizational structure legally establishes its public interest character, rather than commercial profit objectives.

Transparency#

Ladybird’s core development philosophy is a strict, web-standards-first approach. The development team implements features from scratch directly based on the specification documents published by standards bodies like the World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG).

This practice stands in stark contrast to the current model where market leaders de facto define standards through their browser implementations.

The project is committed to complete transparency. All development activities are conducted publicly on GitHub, and the community’s primary communication occurs through a Discord server, where anyone can participate in discussions and contribute code.

Furthermore, the project places user privacy at its core. Its development roadmap includes built-in ad-blocking functionality and explicitly rejects any form of user tracking or data monetization schemes.

Economics#

The Ladybird project is funded entirely by unconditional donations and sponsorships from individuals and corporations, a model that is fundamentally different from that of mainstream browsers.

Most browsers today, including the open-source Firefox, derive their primary income from default search engine agreements. (See above)

Ladybird’s non-profit, donation-only model is not just an alternative fundraising strategy; it is a structural guarantee of its technical and ethical independence.

The main source of revenue for mainstream browsers like Firefox is partnership fees from search engines. This creates a powerful financial incentive that forces them to consider the goals of search engine providers in their decision-making.

These goals often involve user data collection to support advertising businesses, which can conflict with the original intention of protecting user privacy.

Ladybird, through its organizational charter and public commitments, has institutionally severed this revenue stream. By eliminating this potential conflict of interest at the organizational level, the project ensures that its technical decisions (e.g., implementing stronger privacy protections, blocking trackers by default) will never be compromised by the need to please financial partners.

Therefore, its economic model is the solid foundation upon which its user-centric philosophy can be realized.

Features#

Of course, we must return to reality: Is Ladybird actually good to use?

Pre-Alpha#

Currently, Ladybird is still in the pre-alpha stage of development and is not yet suitable for daily use by the average user.

Users who want to experience the browser must compile it from the source code themselves. While this is not difficult for enthusiasts, it presents a high barrier for the general public.

Despite this, the project maintains an active and rapid development pace. The team communicates the latest achievements to the community through forms like monthly progress videos.

These showcases present key metrics such as the number of merged pull requests, the number of new contributors, and the number of passed Web Platform Tests (WPT), all of which attest to the project’s healthy development trajectory.

Compatibility#

In the Web Platform Tests (WPT) suite, the authoritative benchmark for measuring browser engine standards compliance, Ladybird has made impressive progress. As of March 2025, its test pass rate ranked fourth, behind only Chrome, Safari, and Firefox—the three mature browser engines. For a new engine built from scratch, this is a remarkable achievement.

JS Performance#

Ladybird’s self-developed JavaScript engine, LibJS, also performs exceptionally well in terms of standards compliance. WPT results show that LibJS is the second most spec-compliant JavaScript engine, surpassed only by Firefox’s SpiderMonkey engine.

Architecture#

Ladybird’s technical core is its completely self-developed engine components: LibWeb and LibJS.

LibWeb is responsible for handling all tasks related to web content presentation, such as HTML parsing, DOM construction, and CSS rendering.

LibJS is a complete ECMAScript engine responsible for executing the JavaScript code within web pages.

The project was initially written entirely in C++, a choice largely inherited from its technological stack in the SerenityOS project.

After becoming independent, the team is actively evaluating and planning to introduce a memory-safe language (such as Swift) as the project’s second development language, with the aim of enhancing code security and robustness in the future.

Furthermore, in terms of code size, Ladybird’s C++ code is approximately 425,000 lines, whereas the Chromium project’s code size is over 32 million lines. (Although it’s missing a few platforms, it’s very streamlined overall)

This lean architecture brings multiple advantages.

First, it significantly reduces maintenance costs and complexity.

Second, a smaller codebase makes it easier for new contributors to understand how the entire system works, thus lowering the barrier to entry.

Finally, this “hackable” nature encourages experimentation and innovation, creating a favorable environment for rapid iteration and implementation of new features.

Browser engines like Blink and Gecko are massive systems that have accumulated millions of lines of code over decades of development. They inevitably carry the historical complexity of supporting old standards and adapting to architectural evolution.

In contrast, Ladybird was born in the 2020s and was able to be designed from the ground up based on modern software engineering principles (such as multi-process isolation and memory safety), without the need to refactor a vast and deeply entrenched legacy codebase.

Its significantly smaller codebase is easier for a single developer to comprehend fully, which reduces the project’s dependence on a few core developers and facilitates more holistic architectural decisions.

This means that when implementing new web standards or making architectural adjustments, Ladybird may be able to move more quickly than established engines constrained by the inertia of their massive legacy systems.

Multithreading#

Ladybird employs a modern multi-process architecture, which is central to its security design. This architecture strictly isolates the main user interface process from multiple sandboxed WebContent rendering processes, with each browser tab running in its own independent rendering process.

Furthermore, sensitive operations such as image decoding and network requests are also handled in separate processes.

This design is considered a key security advantage. By distributing different functional modules into isolated processes, even if a rendering process crashes or is compromised while handling malicious web content, the impact is confined within that process’s sandbox. This protects the main UI process and the entire operating system, greatly reducing the attack surface.

Challenges#

To become a viable alternative to mainstream browsers, Ladybird’s primary technical challenge is to achieve feature parity with modern browsers.

This is a daunting task, as it means not only implementing a vast and ever-expanding number of Web APIs but also achieving pixel-perfect rendering across a wide variety of websites and supporting complex features like browser extensions and advanced media codecs.

The project is currently in the “make it work” phase and must transition to the “make it good” and “make it fast” phases in the future.

This will require deep optimization of the rendering pipeline and JavaScript execution, which is a resource-intensive and long-term process requiring sustained investment.

On the security front, in addition to the existing architectural-level sandboxing, continuous security hardening is necessary. The maintenance cost of modern browser security is extremely high. Companies like Google spend millions of dollars annually on bug bounty programs, and zero-day exploits against mainstream browsers are frequently demonstrated at top hacking competitions like Pwn2Own.

For Ladybird to gain user trust, it must build an equally robust security response and defense system.

Ladybird’s biggest non-technical obstacle is not just building the browser itself, but overcoming the self-reinforcing Chromium feedback loop in the web ecosystem.

Due to Chromium’s dominant market position, the vast majority of web developers prioritize testing their websites in Chrome. This has led to a web that is de facto optimized for Blink’s specific implementation, including its existing bugs and non-standard behaviors.

When a new browser like Ladybird correctly implements a standard, it may actually encounter rendering errors when visiting websites that rely on Chromium’s specific quirks.

Although Ladybird’s behavior is more spec-compliant, from the user’s perspective, the website is “broken.”

This phenomenon can give users and developers the impression that the new browser is full of bugs, thereby further solidifying their preference for Chromium.

Therefore, Ladybird must not only be standards-compliant but may also need to expend significant engineering resources to achieve compatibility with this Chromium-centric web.

The Warrior#

We have heard many stories of heroes slaying dragons. The emergence of Ladybird is like a warrior who dares to draw their sword in a kingdom overshadowed by the Chromium dragon. We applaud its courage and worry about its slim chances of victory.

We subconsciously ask: Will this warrior eventually become the new dragon?

But perhaps this is the wrong question from the start.

The contest between Google and the US Department of Justice, and the potential new owner of Chrome, are essentially discussions about who will sit on the Iron Throne.

The sword of antitrust may strike down one king, but as long as the throne remains, there will always be another who covets it.

Handing Chrome from one giant to another is likely just passing the crown from one king to the next, without changing the fact that we all live under a king’s rule.

This is the true significance of Ladybird, which transcends the “warrior slays dragon” narrative.

It is not trying to become the new king, but to act as a messenger, bringing a deafening message.

The world does not need a king.

Ladybird’s value lies not in whether it can replace Chrome in the short term, but in its very existence, which is a powerful refutation of the idea that the current state of the web is the only optimal solution.

With every line of code written from scratch, it proves that there is more than one path to the future. It can be a path that returns to openness, is co-built by the community, and puts users, not data, first.

This makes every choice each of us makes more important than ever.

When we choose a browser, we are not just choosing a tool; we are voting for the future we want.

Do we choose a centralized empire ruled by an efficient, benevolent, but sole monarch? Or do we choose a diverse alliance of city-states, perhaps a bit chaotic (is it really that chaotic? E.g., Mastodon vs. X), but full of resilience and freedom?

The ultimate goal of antitrust, perhaps, should not be to prop up more companies to compete for the throne, but to ensure that we always have the right and the possibility to create a world without a throne.

And projects like Ladybird are the sparks that guard this possibility.