How Edge WebView2 Embeds Chromium Without the Bulk

This article explores how Microsoft Edge WebView2 enables developers to embed modern web technologies into native Windows applications without bloating installer sizes. By examining the Evergreen runtime model, the lightweight loader architecture, and operating system-level resource sharing, this guide explains how WebView2 eliminates the need to bundle hundreds of megabytes of Chromium binaries with every individual application.

The Problem with Traditional Browser Bundling

Historically, developers wanting to use HTML, CSS, and JavaScript to build desktop user interfaces relied on frameworks like Electron or the Chromium Embedded Framework (CEF). While effective, these frameworks require the developer to package a complete, standalone version of the Chromium browser inside the application’s installation folder.

Because a full Chromium build easily exceeds 100 to 150 megabytes, installing five different apps built this way results in five separate copies of the exact same browser engine sitting on the user's hard drive. Furthermore, the developer is responsible for updating their entire application just to deliver routine browser security patches.

Decoupling the Engine from the Application

Microsoft Edge WebView2 solves the bloat problem by decoupling the web rendering engine from the application itself. Instead of forcing every application to bring its own browser, WebView2 relies on a single, central installation of the Chromium-based Microsoft Edge rendering engine provided by the Windows operating system.

This shared runtime is pre-installed on all Windows 11 machines and has been automatically rolled out to the vast majority of Windows 10 devices. Because the heavy browser binaries already exist on the user's machine as an OS-level component, individual applications do not need to include them in their installers.

The Lightweight Loader Mechanism

To connect an application to this shared system browser, developers only need to bundle a tiny file called WebView2Loader.dll alongside their application executable.

Instead of weighing hundreds of megabytes, this loader file is only a few hundred kilobytes. When the Windows application launches and needs to display web content, the loader acts as a bridge:

  1. It queries the Windows Registry to locate the centralized WebView2 runtime on the hard drive.
  2. It initializes the shared Chromium engine from that central location.
  3. It embeds the resulting browser view directly into the native application window.

The Evergreen Runtime Model

Microsoft refers to this shared architecture as the "Evergreen" distribution mode. The name signifies that the underlying web engine is always kept up to date, independent of the applications that use it.

Microsoft updates the central WebView2 runtime silently in the background using the standard Windows and Edge update mechanisms. As a result, applications automatically benefit from the latest Chromium performance improvements, web standards, and security patches without the app developer needing to recompile code or push massive updates to their users.

If an application is installed on an older machine that somehow lacks the WebView2 runtime, developers can include an "Evergreen Bootstrapper." This is a micro-installer (under 2 megabytes) that quietly instructs Windows to download and install the shared runtime from Microsoft's servers during the app's setup process.

Memory and Disk Optimization

Beyond saving disk space during installation, the shared runtime model optimizes system memory. When multiple applications using WebView2 are running simultaneously, they do not share user data or browsing sessions—each app runs in its own isolated processes to ensure security and stability. If one app crashes, it will not affect another.

However, because all these applications are calling upon the exact same core Chromium DLL files from the exact same folder on the hard drive, the Windows operating system can load those base binaries into physical RAM once and share the read-only memory pages across all the applications. This reduces the overall memory footprint compared to running multiple independent Electron applications, which must load completely separate, duplicate DLLs into RAM.