Blink is the open-source rendering engine developed within the Chromium project that parses HTML and CSS, builds the document and style structures, computes layout and paints web pages. Among browser technologies it is the engine with the largest share of web traffic, because it powers Google Chrome, Microsoft Edge, Opera, Vivaldi, Brave, Samsung Internet and most Android WebView instances.
Blink began in 2013 as a fork of WebCore, the rendering component of WebKit, when Google decided to pursue its own multi-process architecture and development pace. Since then it has diverged substantially from WebKit and works together with the V8 JavaScript engine, the Skia graphics library and the Chromium networking stack to form a complete browser platform.
How the Blink rendering pipeline works
Blink turns bytes into pixels through a staged rendering pipeline. Each stage produces a data structure that the next stage consumes, and many optimizations consist of skipping stages that do not need to run again after a change.
| Stage | Input | Output |
|---|---|---|
| Parsing | HTML and CSS bytes | DOM tree and style sheets |
| Style | DOM and style rules | Computed style per element |
| Layout | Styled tree | Immutable fragment tree with geometry |
| Pre-paint | Fragment tree | Property trees for transforms, clips and effects |
| Paint | Fragments and property trees | Display lists of drawing commands |
| Commit and compositing | Display lists | Layers handed to the compositor thread |
| Rasterization | Layers and tiles | Pixels drawn through Skia on the GPU |
The main thread runs parsing, style, layout and paint along with JavaScript, while the compositor thread and the GPU process handle scrolling and many animations. This split explains why animations of transform and opacity stay smooth even when the main thread is busy: they can be composited without new layout or paint.
Architecture and major subsystems
Blink runs inside sandboxed renderer processes, typically one per site because of site isolation, which Chromium enabled broadly after the Spectre class of CPU vulnerabilities. A renderer process cannot reach the file system or network directly; it asks the privileged browser process through the Mojo IPC system.
Over the last decade the engine went through several large rewrites. LayoutNG replaced the legacy layout code with a fragment-based model that handles block fragmentation, multi-column layout and printing more consistently. RenderingNG is the umbrella name for the redesigned pipeline, including composite after paint, which decides layer boundaries only after painting and reduced memory use and bugs.
| Component | Responsibility | Relation to Blink |
|---|---|---|
| V8 | JavaScript and WebAssembly execution | Embedded through bindings |
| Skia | 2D graphics and rasterization | Draws Blink display lists |
| cc (compositor) | Layer management and scrolling | Receives committed layers |
| Network service | HTTP, caching, cookies | Supplies resources over IPC |
| Browser process | Tabs, permissions, storage access | Brokers privileged operations |
Blink compared with WebKit and Gecko
Blink is one of three major rendering engines still developed independently, alongside WebKit and Gecko. The differences lie less in which standards they support and more in architecture, release process and governance.
| Property | Blink | WebKit | Gecko |
|---|---|---|---|
| Main browsers | Chrome, Edge, Opera | Safari | Firefox |
| Lead organization | Google with Chromium contributors | Apple | Mozilla |
| JavaScript engine | V8 | JavaScriptCore | SpiderMonkey |
| Implementation language | C++ | C++ | C++ and Rust |
| Release cadence | About four weeks | Tied to Safari releases | About four weeks |
| Origin | Fork of WebKit in 2013 | Fork of KHTML in 2001 | Netscape codebase |
Because so many browsers share Blink, its behavior effectively defines web compatibility for a large part of the web. Critics describe this as a monoculture risk: when one engine dominates, sites may be tested only against it, and its implementation choices can shape standards before other engines agree.
How features ship in Blink
New web platform features in Blink follow a public launch process rather than appearing silently. Engineers announce an Intent to Prototype, build the feature behind a flag, often run an origin trial with real sites, and then post an Intent to Ship that needs approval from Blink API owners.
- Runtime flags let developers test unfinished features locally through browser settings.
- Origin trials expose a feature to registered sites for a limited period to collect feedback.
- Deprecation and removal of features also go through public intents with usage data.
- Interoperability efforts such as the annual Interop project align Blink, WebKit and Gecko on chosen features.
For developers, this means a feature that is available in Chrome is not automatically a web standard. Checking whether WebKit and Gecko have shipped or signaled support is essential before relying on a Blink-only capability in production.
Practical implications for web developers
Understanding Blink helps developers diagnose performance and rendering issues with Chromium DevTools, whose Performance panel labels work by pipeline stage: recalculate style, layout, paint and composite layers. The table below links common symptoms to their likely engine-level cause.
| Symptom | Likely cause | Typical fix |
|---|---|---|
| Long layout tasks | Forced synchronous layout in loops | Batch DOM reads before writes |
| Janky scrolling | Main-thread work during scroll | Passive listeners and fewer handlers |
| Expensive repaints | Animating layout properties | Animate transform and opacity instead |
| High memory use | Too many composited layers | Limit will-change to active elements |
A common misconception is that testing in Chrome covers all Blink browsers. They share the engine, but each vendor adds its own features, flags, privacy defaults and release timing, so Edge or Samsung Internet can still behave differently in details such as tracking protection or form autofill.
In everyday language
A web page arrives as text written in special languages that describe content, layout and behavior. Something has to read that text and draw the actual page on the screen, much like a printer turns a document file into ink on paper. Blink is that drawing machine inside Chrome, Edge and many other browsers.
Because so many browsers use the same machine, websites look and behave alike in all of them. The downside is that when one machine serves most of the world, its quirks and choices affect almost everyone.
Seen in the real world
A retail company notices that its product listing page stutters while scrolling on mid-range Android phones. Because Chrome and the in-app WebView on those phones both use Blink, the front-end team records a trace in Chromium DevTools and sees long purple layout blocks of about 80 milliseconds repeating during scroll.
The trace shows that a scroll handler reads each card’s height and then changes its style, forcing Blink to recalculate layout repeatedly within a single frame. The team moves the measurements into one batch, switches the sticky header animation to transform and marks the scroll listener as passive. After the change, scrolling stays close to 60 frames per second on the same devices, and the improvement carries over to every Blink-based browser their customers use.