Google Releases Blink as a New Browser Engine

Google announced Blink on April 3, 2013 as a fork of the WebCore component of WebKit — the rendering engine Google had used in Chrome since its initial release on September 2, 2008. WebKit itself had origins in KHTML, the rendering engine developed by the KDE project for the Konqueror browser, which Apple forked in January 2003 to create Safari. Chrome had adopted WebKit because it was already mature, standards-compliant, and open-source, but Chrome immediately diverged from Safari’s architecture by using V8 (Google’s own JavaScript engine, developed separately) rather than WebKit’s JavaScriptCore, and by implementing a multi-process model in which each browser tab ran in a separate sandboxed renderer process. This multi-process architecture — fundamental to Chrome’s stability and security properties — created permanent architectural tension with WebKit, which had been designed for a single-process model. Chrome engineers working in the shared WebKit repository found themselves maintaining complex compatibility layers and workarounds to support Chrome’s multi-process design in a codebase whose primary consumers (Apple Safari) used a different architecture. Opera simultaneously announced it was also abandoning its long-running Presto rendering engine in favor of Blink, becoming the third major browser to share a Chromium-based engine alongside Chrome and the various Chromium-derived browsers already in existence.

Blink’s initial creation involved forking approximately 4.5 million lines of the WebCore rendering code from WebKit. The first major cleanup step was removing code paths used exclusively by Safari or other non-Chrome WebKit ports: Google engineers deleted approximately 7,000 files in the first weeks, simplifying the codebase substantially. The development philosophy Blink adopted differed from WebKit’s in ways that had long-term consequences for web standards: Blink’s team moved faster on implementing experimental APIs, shipping features like Service Workers (Chrome 40, January 2015; Firefox 44, January 2016; Safari 11.1, March 2018 — a 3-year gap) and Web Bluetooth, Web USB, and Web Serial as Blink-only APIs that remained unavailable in other engines for years or entirely. This created tensions in web standards bodies (W3C, WHATWG): Blink’s ability to ship features at Chrome’s scale effectively allowed Google to establish de facto standards by deployment before formal specification completion, a concern that became more acute as Blink’s market share grew. Microsoft announced in December 2018 that it was abandoning EdgeHTML (its own Trident-derived engine used in the original Edge browser) in favor of Chromium/Blink, with Chromium-based Edge releasing January 15, 2020. After that transition, Blink and its derivatives became the rendering engine for Chrome, Chromium, Edge, Opera, Vivaldi, Brave, Samsung Internet, and hundreds of embedded browsers — leaving Mozilla’s Gecko (Firefox) and Apple’s WebKit (Safari, and all iOS browsers due to Apple’s App Store policy requiring WebKit for iOS) as the only remaining independent browser engine implementations with meaningful market share.

The browser engine consolidation around Blink raised concerns among web standards advocates and regulators that went beyond technical considerations. Browser engines are the implementations of web platform standards: HTML parsing, CSS layout algorithms, JavaScript execution (through the V8 engine), Web APIs (Fetch, WebRTC, WebAssembly, WebGPU), accessibility tree construction, and security policies (same-origin policy, Content Security Policy, mixed content blocking) are all implemented in browser engines. When a single engine controls how the majority of users experience the web, the engine’s implementation choices — bugs, intentional interpretations, performance characteristics, and decisions about which standards to implement first — effectively define the web platform for most users and developers. Mozilla launched Project Quantum (Firefox 57, November 2017) to modernize Gecko’s performance using Rust components, specifically as an alternative to browser engine monoculture. The UK Competition and Markets Authority, in its 2021 Mobile Ecosystems Market Study, identified the Apple requirement that all iOS browsers use WebKit as anticompetitive, and subsequently required (as part of the Digital Markets Act implementation in the EU, March 2024) that Apple allow third-party browser engines on iOS in the European market — the first regulatory intervention directly targeting browser engine choice as a platform competition issue.