When Chromium Shares Renderer Processes Across Tabs

This article explores the specific scenarios in which the Chromium web browser assigns multiple tabs from the same origin to a single renderer process. While Chromium generally attempts to isolate tabs into separate processes to maximize performance and stability, it will consolidate same-origin tabs into one process when the tabs are directly linked via scripts, when the system reaches memory or process limits, or when specific browser policies dictate consolidation.

1. Connected Tabs (Same BrowsingInstance)

By default, Chromium uses a "process-per-site-instance" model. If a user opens a new tab and types in a URL, that tab gets a brand-new renderer process, even if another tab with that exact same URL is already open.

However, Chromium must share a single renderer process when two tabs from the same origin are "connected" and belong to the same BrowsingInstance. This happens when:

  • One tab opens another same-origin tab using JavaScript, such as window.open().
  • A user clicks a link that opens a new tab where the rel="opener" attribute is explicitly set.

Because the HTML specification allows these connected tabs to synchronously access each other's Document Object Model (DOM) and JavaScript variables (via window.opener), Chromium is forced to place them in the exact same renderer process so they share the same memory space and execution thread.

2. Reaching the Maximum Process Limit

Chromium cannot spawn an infinite number of processes. To prevent the browser from exhausting the host operating system's memory, Chromium enforces a soft limit on the total number of active renderer processes. This limit is dynamically calculated based on the device's available RAM and CPU cores.

When a user opens enough tabs to hit this process limit, Chromium shifts its strategy. If a user opens a new tab for example.com and the process limit has already been reached, Chromium will scan existing processes. Instead of creating a new process or randomly picking an unrelated one, it will find an existing example.com renderer process and place the new tab inside it. This allows Chromium to cap memory usage without violating Site Isolation security boundaries.

3. Aggressive Reuse on Low-Memory Devices

On devices with tight memory constraints, such as low-end Android phones, Chromium does not wait for a high process limit to be reached. Instead, it aggressively reuses renderer processes for same-origin tabs as soon as possible. If the system detects memory pressure, the browser prioritizes keeping the memory footprint low over isolating individual same-origin tabs for performance.

4. Browser Extensions and Internal Pages

Chromium abandons its standard process model and strictly enforces a "process-per-site" model for specific types of origins:

  • Browser Extensions: All tabs, popups, and background frames belonging to a single chrome-extension:// origin will always share a single renderer process.
  • WebUI Pages: Internal browser pages (such as chrome://settings or chrome://history) will share a single process with other tabs of the exact same internal origin to conserve system resources.

5. Explicit Command-Line Flags

Users and administrators can force Chromium to always share a single renderer process for all tabs of the same origin, regardless of how they were opened or how much RAM is available. Launching the browser with the --process-per-site command-line flag overrides the default behavior and groups all same-site tabs into one shared process immediately.

Exceptions: When Same-Origin Sharing is Blocked

Even if the above conditions are met, Chromium will refuse to share a renderer process between two tabs of the same origin if:

  • Different Profiles: One tab is in a standard window and the other is in an Incognito window (or a different user profile).
  • Security Headers: One of the tabs serves a strict Cross-Origin-Opener-Policy (COOP) or Cross-Origin-Embedder-Policy (COEP) header that mismatches the other tab, requiring strict process isolation at the browser level.
  • Sandboxed Tabs: One of the pages is loaded with specific Content Security Policy (CSP) sandbox directives that strip it of its standard origin privileges.