Where Blink and V8 sit inside Chromium: the browser, renderer, GPU and network processes, why they are split, and how Site Isolation fits in.
Open Chrome's built-in task manager and you will not see one program called "Chrome" — you will see a list of separate processes: one for the browser itself, one or more for web pages, one for the GPU, one for the network. That list is the whole architecture in miniature. Chromium, the open-source project underneath Chrome, Edge, Brave and Opera, is not a single engine running in one block of memory. It is a set of cooperating processes, and Blink (the rendering engine) and V8 (the JavaScript engine) live in only one kind of them. This guide answers a single question: where do Blink and V8 sit inside Chromium, and how do the processes divide the work?
Key Takeaways
- Chromium runs as multiple processes: a privileged browser process that owns the UI, tabs and coordination, plus sandboxed renderer processes, a GPU process, and network and other utility services.
- Blink and V8 run inside the renderer process. That is the part that parses HTML, runs your page's JavaScript and works out layout — and it is deliberately the least-trusted part.
- The split exists for stability and security: a crashed page should not take down the whole browser, and a compromised page should not be able to read your files or other sites.
- Site Isolation goes further and tries to keep pages from different sites in different renderer processes, a defense strengthened after the Spectre CPU vulnerabilities.
- Every Chromium-based browser shares this layout, which is one reason engine-level traits are hard to fake.
The one-sentence model
The Chromium multi-process architecture design document describes the idea plainly: run the code that handles untrusted web content in separate, restricted processes, and keep a single privileged process in charge. Google's Inside look at modern web browser series tells the same story from the user's side, using the same cast of processes. If you want the background on what an engine is first, start with browser engines explained and come back.
Who runs where
Chromium has changed its exact process layout over the years, and the design document is historical in places, so treat the details below as the stable core rather than a current process list. Both sources agree on these roles.
| Process | What runs there | What it can touch |
|---|---|---|
| Browser | The window, address bar, bookmarks, back and forward buttons; coordinates every other process | The most privileged: files, system resources, the UI, and control over every other process |
| Renderer | Blink (HTML, CSS, layout, painting) and V8 (JavaScript) for web content | Very little: runs in a sandbox and must ask the browser process for anything outside it |
| GPU | Work handed to the graphics hardware, such as compositing and drawing | The graphics driver, isolated from the pages that request the drawing |
| Network and other utility services | Fetching resources, plus helper tasks that are safer outside the browser process | Network access, without sharing a process with page code |
The key observation is the middle row. A tab's page content is handled by a renderer process, and that is where both halves of the engine pair meet. If you read rendering engine vs JavaScript engine, the "two engines cooperating on a page load" described there is happening inside one renderer process: Blink builds the DOM and layout, V8 runs scripts that can change them, and neither crosses a process boundary to do it.
Why split the browser up at all
Two problems drove the design, both described in the design document and Google's walkthrough.
Crashes. Pages run arbitrary code and sometimes hang or crash. If everything shared one process, one bad tab would take every other tab and your session with it. With separate renderer processes, a crash is contained: the browser process stays alive and can show the familiar "this page crashed" message for that one tab.
Sandboxing. Blink and V8 are huge, complex programs that parse hostile input all day, so bugs are inevitable. Chromium assumes some of them will be exploitable and limits the damage: the renderer runs with restricted privileges, and when it needs to read a file or open a network connection it has to ask the browser process (and the services it brokers), which can refuse. A compromise of the renderer is therefore not automatically a compromise of your machine. The cost is overhead: more processes use more memory and need message passing between them, a trade-off the Chromium team has accepted for the safety it buys.
Site Isolation: one site, one process
A tab does not equal a process, and the process boundary matters most between websites. Site Isolation aims to ensure that a renderer process only holds pages from a single site, so a page from one site cannot sit in the same process memory as a page from another — including embedded iframes, which can be rendered out of process from the page that embeds them. Chrome turned Site Isolation on by default for desktop users in Chrome 67 in 2018; on Android it is applied more selectively, because phones have less memory to spare.
The motivation sharpened after Spectre, the class of CPU speculative-execution flaws disclosed in 2018. Spectre-style attacks can let code read memory from elsewhere in its own process, so a malicious page that shares a process with a bank's page could, in principle, try to read data it should never see. Putting the two in different processes takes that memory out of reach, and it lets the browser process act as the referee instead of trusting the page. The timer side of the same story — why browsers coarsened clocks to make these attacks harder — is covered in browser timer precision.
We are not going to put numbers on the memory or performance cost here, because they vary heavily by device, page and Chromium version, and the official pages do not give a single figure worth quoting.
See it on your own machine
You do not need any special tools to watch this architecture at work:
- Task manager. In Chrome, open the menu, then More tools → Task manager (or press Shift+Esc on Windows, Linux and ChromeOS). Each row is a process: the browser, the GPU process, utility services such as the network service, and the renderers, each labelled with the tabs or frames it serves. Open two tabs on the same site and two on different sites, then compare the process IDs.
- chrome://process-internals. This internal page shows which Site Isolation mode the browser is running and which frames live in which process. Type it into the address bar yourself; web pages are not allowed to link to it.
What this means for the fingerprinting side
For BrowserInsight readers there is a practical consequence. Edge, Brave, Opera, Vivaldi and Chrome all inherit this structure from Chromium; they differ in branding, defaults and services, not in the fact that Blink and V8 run in a sandboxed renderer. That is why our kernel check reports the Blink/Chromium engine for all of them, as discussed in Chromium vs Chrome and why so many browsers use Chromium.
It is also why engine-level behaviors are hard to imitate. A script can fake a user-agent string, but it cannot change which JavaScript engine actually executes the code (JavaScript engine fingerprinting), and the set of web features a build supports follows its version (engine version feature detection). Headless Chrome runs the same Blink and V8 stack, which is why automation is detected through behavior and consistency checks rather than a different engine — see bot detection techniques.
One honest limit: the kernel check identifies the engine and its version from which features the browser supports. It does not inspect your processes or tell you whether Site Isolation is on. For that, use the task manager and chrome://process-internals described above.
Frequently Asked Questions
Is Chromium one process or many?
Many. A privileged browser process coordinates sandboxed renderer processes, a GPU process and network and utility services. The exact number changes with the pages you open and the Chromium version.
Do Blink and V8 run in the browser process?
No. Both run in the renderer process, in a sandbox, because they handle untrusted web content. The browser process handles the interface, coordination and anything that needs elevated access.
Does every tab get its own process?
Not strictly. Tabs and sites are related but not identical: Site Isolation aims for one site per renderer process, and embedded cross-site frames can live in a different process than the page around them. Chromium may also share or reuse processes in some situations.
Does this make Chrome safer than other browsers?
It makes Chromium-based browsers harder to exploit in some ways, but process isolation is one layer among many, and other engines have their own multi-process designs. Safety also depends on updates, extensions and your own behavior.
Conclusion
Chromium is best read as a small organization rather than a single program: one privileged manager, a handful of specialists, and a sandboxed renderer where Blink and V8 do the work of turning a hostile page into pixels. The split buys crash containment and a smaller blast radius, and Site Isolation extends that to separating websites from one another. Knowing where the engines sit explains a lot about why Chromium browsers behave alike and why that shared stack is so useful for telling real browsers from imitations.
