webview: Cross-Platform C/C++ Webview Library for Desktop GUI

What webview Solves and Who It Is For

C and C++ desktop applications traditionally use platform-native GUI toolkits, which means writing different code for each target platform or adopting a cross-platform widget library such as Qt or wxWidgets. Both approaches require learning a toolkit-specific API and shipping the toolkit as a dependency.

webview takes a different approach. It opens a single native browser window and lets the developer build the interface in HTML and JavaScript. Two-way bindings allow calling C/C++ from JavaScript and JavaScript from C/C++. The library's stated goal is to create a common HTML5 UI abstraction layer for the most widely used platforms.

The target audience is C and C++ developers who are comfortable with web front-end technologies and want to avoid a heavy GUI toolkit, as well as developers porting web-based prototypes to desktop without rewriting the UI layer.

Platform Coverage and the Browser Engines Used

webview supports three platforms, each using a different browser engine:

- Linux: GTK and WebKitGTK. Multiple GTK and WebKitGTK version combinations are supported, including WebKitGTK 6.0 with GTK 4, WebKitGTK 4.1 with GTK 3 and libsoup 3, and WebKitGTK 4.0 with GTK 3 and libsoup 2. - macOS: Cocoa and WebKit. - Windows: Windows API and Microsoft Edge WebView2.

This means the rendered page depends on the engine available on the target machine. WebKitGTK and WebKit are both well-maintained but are not byte-for-byte identical in behavior. CSS and JavaScript features that work on one may behave differently on another. Developers building cross-platform applications need to test on all three platforms.

The Go language binding has been moved to a separate repository. Versions of the Go binding at 0.1.1 and below remain in this repository, and newer Go development happens elsewhere.

Prerequisites and Building the First Application

On Linux, GTK and WebKitGTK development packages are required. The README provides the Debian and Fedora package names for each supported GTK/WebKitGTK combination. On Debian with WebKitGTK 6.0 and GTK 4:

apt install libgtk-4-dev libwebkitgtk-6.0-dev

On Windows, end users must have the WebView2 runtime installed on any Windows version before Windows 11. The compiler must support C++14 and Visual Studio 2022 or later is recommended for Visual C++.

The recommended build system is CMake with Ninja. A minimal C++ project using CMake's `FetchContent` to pull webview:

FetchContent_Declare(
    webview
    GIT_REPOSITORY https://github.com/webview/webview
    GIT_TAG 0.12.0)
FetchContent_MakeAvailable(webview)

Link the target against `webview::core` for C++ or `webview::core_static` for C. Build with:

cmake -G Ninja -B build -S . -D CMAKE_BUILD_TYPE=Release
cmake --build build

The final binary ends up in `build/bin`.

For non-CMake usage, the README describes building with GCC or Clang-like compilers directly. On Linux with GTK 3 and WebKitGTK 4.0, the compile command uses pkg-config output. On macOS, the WebKit framework is linked with -framework WebKit. On Windows, additional Windows libraries are required: advapi32, ole32, shell32, shlwapi, user32, and version.

An amalgamated library can be built that combines all source files into a single header. The amalgamate.py script at scripts/amalgamate/amalgamate.py produces this output. The resulting webview_amalgamation.h can be dropped into a project without any CMake configuration. This is useful for projects that copy-vendor their dependencies rather than managing them with a package manager.

The repository's examples directory includes basic.c, basic.cc, bind.c, and bind.cc. The bind examples demonstrate the two-way JavaScript binding interface, which is the mechanism for calling C or C++ functions from JavaScript running inside the webview window. The examples directory also has a resources subdirectory.

Two-Way JavaScript Bindings

The library supports calling JavaScript from C/C++ and calling C/C++ from JavaScript. The README lists this as a core capability. A minimal C++ example from the README creates a window, sets its title and size, and renders an HTML string:

#include "webview/webview.h"
#include <iostream>

int main() {
  try {
    webview::webview w(false, nullptr);
    w.set_title("Basic Example");
    w.set_size(480, 320, WEBVIEW_HINT_NONE);
    w.set_html("Thanks for using webview!");
    w.run();
  } catch (const webview::exception &e) {
    std::cerr << e.what() << '\n';
    return 1;
  }
  return 0;
}

The `examples/` directory contains additional examples including `bind.cc` and `bind.c` that demonstrate the JavaScript binding interface. The README directs developers to the source code for the most up-to-date documentation, noting that documentation is a continuous improvement effort.

Known Constraints and the WebView2 Runtime Dependency

The most significant operational constraint on Windows is the WebView2 runtime. On Windows 11 it is bundled with the OS. On earlier Windows versions, end users must install it separately from Microsoft. Applications that ship to managed enterprise environments or to users unlikely to install prerequisites face a distribution problem that an Electron-based application would not have, since Electron bundles its own Chromium.

On BSD-based systems, the README notes that execution may require the `wxallowed` option in fstab to bypass W^X memory protection. The README explicitly says to check whether the application works without disabling this security feature first.

The library uses the system browser engine, which means there is no version pinning: a WebKitGTK update or a WebView2 update changes the rendering engine version for all applications on that machine. This is a stability consideration for applications with strict UI consistency requirements.

For non-CMake usage, the README describes building an amalgamated header using `amalgamate.py`, which produces a single `webview_amalgamation.h` file.

Alternatives and Maintenance State

Electron is the main alternative. Electron bundles Chromium and Node.js into the application, which guarantees consistent rendering across platforms and a rich JavaScript ecosystem, at the cost of a binary size in the hundreds of megabytes. webview produces far smaller binaries but relies on system-installed engines.

Tauri is a more recent alternative that takes a similar approach to webview: it uses the system's browser engine on each platform and exposes a Rust back-end rather than C/C++. Tauri has an active release cycle and a larger ecosystem of plugins. Developers choosing between webview and Tauri should consider whether Rust or C/C++ better fits the existing codebase.

The last push to the webview repository was on 2026-03-09. The project has no GitHub releases listed. The repository is not archived, but the absence of recent activity means new platform support or API changes should not be expected. The license is MIT.

Editorial conclusion

webview is the right choice for C or C++ developers who want to ship a desktop application with an HTML5 front-end and need a minimal dependency footprint. It is not suitable for projects that need a full Electron-style bundled runtime: webview relies on whatever browser engine is present on the end user's machine, which means layout differences are possible across platforms. On Windows before Windows 11, end users must have the WebView2 runtime installed. The last push to this repository was on 2026-03-09, with a gap of more than six months from that date to the time of writing, so new features should not be expected.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. webview/webview on GitHub