CefSharp vs WebView2: which to use in a .NET app

If you build a Windows desktop app in C# and need to show web content, you will end up choosing between these two. Both render with Chromium, so most pages look the same in either. The real differences are in how the engine reaches the user’s machine, how it is updated, and how much control your code has over it. For the wider picture, including WKWebView on Apple platforms, see CEF vs WebView2 vs WKWebView.

What is the difference between CefSharp and WebView2?

CefSharp is an open-source .NET wrapper that bundles its own Chromium inside your app. WebView2 is Microsoft’s control that uses the Edge runtime already on the machine. Both render with Chromium on Windows; they differ in who ships the engine, how it updates and how much control you get.

Who updates Chromium in CefSharp and WebView2?

With WebView2 in Evergreen mode, Microsoft updates the shared runtime for you. With CefSharp, you update Chromium yourself by upgrading the NuGet package and shipping a new version of your app.

Chrome now ships a new major version every two weeks, with security fixes in between. Every embedded Chromium has to keep up with that somehow.

With WebView2 in Evergreen mode, the runtime is shared by all apps on the machine and Microsoft updates it, the same way it updates Edge. Your app gets security fixes without a release. The catch is that the engine can change under your app without warning, so test against the Edge preview channels to catch breaking changes early.

With CefSharp, each release is built on a specific CEF and Chromium version. Your users get a Chromium fix only when you upgrade the package, test, and ship. That gives you a known engine version, which matters on locked-down fleets. It also means you need a release habit that keeps pace with Chromium, or you knowingly run an engine with published security holes. Our guide to Chrome’s two-week release cycle explains how to choose that pace.

WebView2 also has a Fixed Version mode, where you bundle a specific runtime with your app. It gives you the same control as CefSharp, and the same duty to update it yourself.

How do CefSharp and WebView2 work in WinForms and WPF?

Both have WinForms and WPF controls. CefSharp’s WPF control uses off-screen rendering, so WPF content can overlap it. The standard WebView2 WPF control is window-hosted, so nothing can be drawn over it unless you use WebView2CompositionControl.

The CefSharp WinForms control renders into a normal child window. The CefSharp WPF control uses off-screen rendering: Chromium draws each frame into a buffer and WPF displays it. That avoids WPF’s airspace problem, so you can place WPF elements over the browser, but it costs more CPU and GPU work than a windowed control.

The standard WebView2 WPF control is hosted in its own window, so WPF content cannot overlap it. Microsoft added WebView2CompositionControl to the same package to fix this. It draws the web content through WPF composition instead. If your UI layers controls over the browser, try it early and measure it.

How do you call JavaScript and intercept requests in each one?

Both can run scripts and return results, expose .NET objects to the page, and intercept requests. CefSharp gives deeper control over requests and custom URL schemes; WebView2 covers the common cases with simpler APIs.

• Calling JavaScript. Both let you run script in the page and read the result: EvaluateScriptAsync in CefSharp, ExecuteScriptAsync in WebView2.
• Exposing .NET objects to the page. CefSharp binds .NET objects to JavaScript through its JavaScript binding API. WebView2 offers AddHostObjectToScript, plus a simpler message channel with PostWebMessageAsJson and the WebMessageReceived event.
• Intercepting requests. CefSharp’s request handlers can inspect, change, redirect or block requests, and you can register custom URL schemes. WebView2’s WebResourceRequested event covers the common cases, such as serving a response from your app or adding headers.
• Loading local files. CefSharp uses scheme handlers. WebView2 can map a virtual host name to a local folder with SetVirtualHostNameToFolderMapping.

If your app relies on very detailed request control, such as rewriting traffic for every frame or custom protocols across the whole browser, CefSharp usually gives you more to work with.

What deployment problems should you plan for?

CefSharp needs the Visual C++ 2022 runtime and can only be initialised once per process. WebView2 needs its runtime on the machine, which Windows 11 includes, and a writable user data folder for each app.

• CefSharp: it needs the Visual C++ 2022 runtime, which you can install or ship with your app. It starts several CefSharp.BrowserSubprocess.exe processes, which is normal. CEF can only be initialized once per process, so set your settings and register custom schemes before you call Cef.Initialize.
• WebView2: the runtime is preinstalled on Windows 11. For Windows 10 and older images, ship Microsoft’s Evergreen bootstrapper or installer rather than assuming it is there. Each app also needs a writable user data folder, which matters when the app is installed under Program Files.

When should you choose WebView2?

Choose WebView2 for most new Windows apps: it gives the smallest installer, and Microsoft handles Chromium security updates.

• You are starting a new Windows app and want the smallest installer.
• You would rather Microsoft handle Chromium security updates than run that process yourself.
• You use WinUI, or want one control across WinForms, WPF and WinUI.

When should you choose CefSharp?

Choose CefSharp when you need off-screen rendering, a pinned engine version you test yourself, or deep control over requests, and you can ship Chromium updates on a steady schedule.

• You need off-screen rendering, for example for video walls, custom compositing or rendering pages to images.
• You must pin and test the exact engine version, as on kiosks, POS terminals and other managed fleets.
• You need deep control over requests or custom URL schemes across the whole browser.
• Your app already uses CefSharp and works well. Switching is real work; do it for a clear reason.

If you are moving from CefSharp to WebView2, the hard parts are usually the JavaScript bridge, request interception and any off-screen rendering, not the page loading itself. List those first and test them in a small prototype before you commit.