webui-dev/webui: a browser as your C or C++ GUI, without bundling Chromium
Use any web browser or WebView as GUI, with your preferred language in the backend and modern web technologies in the frontend, all in a lightweight portable library.
At a glance
- What is it?
- WebUI is a small C library that opens an installed browser as the window for a native program and talks to it over a binary WebSocket. It fits C and C++ desktop tools that want HTML for the interface; it does not fit anything that needs an offline, self-contained runtime.
- Who is it for?
- Adopt WebUI if you ship a C or C++ desktop tool and want HTML for the interface without carrying a browser engine, and if you can accept that the user's installed browser is the runtime. Do not adopt it if the machine may have no browser, or if the UI must look identical everywhere.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem WebUI solves: HTML interfaces without a bundled browser engine
Most desktop GUI toolkits make you choose. You either write native widgets in C or C++, which is fast and portable but dated in appearance, or you ship a web runtime. Electron and NW.js embed Chromium and Node.js, so every install carries a full browser. Tauri and Qt avoid that but still pull in platform runtimes: WebView2 on Windows, GTK and WebKitGTK on Linux, WKWebView on macOS. The README's own dependency table lists those, and it lists WebUI's row as "Only A Web Browser" on all three platforms.
That is the whole pitch. WebUI is a small library that starts a browser the user already has and uses it as the window. The README calls it a WebView controller where the controller is not embedded in your program. The audience is narrow and specific: developers writing C or C++ tools, utilities or internal applications who want a modern interface, and who control the machines the software runs on, or can assume a browser is present. It is not aimed at web developers, and it is not a way to host a website.
How the bridge works: a local server, a private profile, and webui.js
The library embeds CivetWeb, a small C web server. The Makefile shows it compiled from src/civetweb/civetweb.c with the defines NDEBUG, NO_CACHING, NO_CGI and USE_WEBSOCKET, and the webui.c source compiled alongside it. So the process that runs your C code also listens on a local port and serves the page.
The frontend loads a script called webui.js. In the minimal C example in the README, the HTML passed to webui_show contains `<script src="webui.js"></script>`, which is what wires the page to the backend. Communication runs over a WebSocket, which the README describes as a fast binary protocol rather than JSON text. The README also states that WebUI uses a private profile for safety, meaning the browser is launched in a way that does not reuse the user's normal session. That matters: it keeps cookies and extensions out of your application's window, and it is the reason a login-style flow behaves differently from a normal browser tab.
The window itself is created with webui_new_window() and displayed with webui_show(), and webui_wait() blocks until the window closes. A cross-platform WebView is available as an option, but the README marks it optional; the browser path is the default design.
Installing WebUI and running a first window
WebUI is not distributed as a package you install first. You build the library from the repository. On Linux with GCC the README gives `make`, and `make CC=clang` for Clang. On macOS the default is also `make`. On Windows the README lists `mingw32-make` for GCC and `nmake` for MSVC. The repository also carries CMakeLists.txt, build.zig, conanfile.py and vcpkg.json, so CMake, Zig, Conan and vcpkg are alternative entry points.
git clone https://github.com/webui-dev/webui.git
cd webui
makeAfter the build you get the library plus a single header, include/webui.h for C and include/webui.hpp for C++. The README's minimal program is short enough to paste whole.
#include "webui.h"
int main() {
size_t my_window = webui_new_window();
webui_show(my_window, "<html><head><script src=\"webui.js\"></script></head> Hello World ! </html>");
webui_wait();
return 0;
}Compile it against the built library and run it. A browser window should open showing the string. Because the HTML is passed as a string here, there is no document root to configure for this first test; the library serves the page itself. If you want TLS, the README documents an optional build flag, WEBUI_USE_TLS=1, with WEBUI_TLS_INCLUDE and WEBUI_TLS_LIB on Windows, libssl-dev on Linux, and openssl from Homebrew on macOS. The output library is renamed webui-2-secure when TLS is on, per the Makefile.
The browser is the runtime, and that is the failure mode
The dependency table is honest about the trade. WebUI needs only a browser, which is also the constraint. If a target machine has no browser, or has one the library cannot find or launch, there is no window. A bundled-runtime application degrades to a slow start; WebUI degrades to nothing. The README does not document a fallback path for that case, and it does not document rollback or recovery behaviour when browser discovery fails.
Rendering is whatever the installed browser does. Two users on different browsers, or on different versions of the same browser, can see different output, and the README's multi-browser support is presented as a feature rather than a guarantee of identical rendering. For an internal tool this is usually fine. For a product where pixel-level consistency is part of the deal, it is a real cost that no amount of HTML discipline removes. The private profile also means the user cannot bring their own extensions or saved logins into the window, which is a safety property and a usability limitation at the same time.
The release situation deserves attention too. The README header reads WebUI v2.5.0-beta.4, while the listed releases are 2.5.0-beta.3 from 2025-03-07 and 2.5.0-beta.2 from 2024-07-13, plus a nightly tag. The last push to the repository was on 2026-08-14. A project whose headline version is a beta, with betas spaced more than a year apart, is one where you should pin an exact tag and read the changelog rather than track main.
WebUI compared with Tauri: same idea, different boundary
Tauri is the closest comparison and the README makes it directly. Both let you build the interface in HTML, CSS and JavaScript and keep the logic in a compiled language. The difference is where the rendering engine comes from. Tauri binds to the platform WebView: WebView2 on Windows, WebKitGTK on Linux, WKWebView on macOS. That gives a consistent embedding API and a window that is part of your process, at the cost of runtime dependencies the README lists explicitly.
WebUI goes the other way. It launches a real browser and talks to it over a socket. You get the full feature set of a modern browser instead of a WebView subset, and the binary stays small, but you give up the guarantee that the runtime exists and that it behaves the same way everywhere. Tauri's backend is Rust; WebUI's is C with a single header and bindings for other languages. If your project is already Rust and you want a managed WebView, Tauri's model is the better fit. If your project is C or C++ and you want the smallest possible artifact, WebUI's model is the one that matches.
Licence and the cost of keeping up
WebUI is MIT licensed, per the repository metadata and the LICENSE file at the top level. That is a permissive licence, and it is the same family as many of the tools it competes with. Nothing here suggests a copyleft obligation or a commercial tier. This is a description of the licence, not legal advice; read the LICENSE file yourself before you depend on it.
The upgrade cost is the part people underestimate. The bridge is a binary WebSocket protocol, and the frontend half of it lives in webui.js. If the protocol changes between versions, a page written against one release may not work against another, so the library version and the script are effectively one unit. The README does not document protocol versioning or a compatibility policy. The practical consequence is that you should vendor the header and the script together, and treat a version bump as a change that needs a test pass rather than a routine dependency update. The optional TLS build adds its own moving part: OpenSSL is linked in on Windows and Linux, which means a second thing to keep patched.
A small window, and what it is not
The README lists the features plainly: portable, single header, a few kilobytes, small memory footprint, binary WebSocket, multi-platform and multi-browser, private profile, optional cross-platform WebView. Taken together they describe a specific kind of tool. It is a way to put a modern interface on a program that would otherwise draw its own widgets. The examples directory carries C and C++ samples plus two starter kits, and one of the screenshots is a frameless window on both Windows and Linux, which shows the kind of chrome-free panel people build with it.
What it is not: a server framework, a way to expose a local app to the network, or a replacement for a full web stack. The local server exists to feed one window, and the README does not present it as anything else. If you need a browser-accessible service with users and sessions, that is a different project. If you need a native binary that happens to render its interface with HTML, and you can live with the browser being a prerequisite, WebUI is built for exactly that case.
Editorial conclusion
Adopt WebUI if you ship a C or C++ desktop tool and want HTML for the interface without carrying a browser engine, and if you can accept that the user's installed browser is the runtime. Do not adopt it if the machine may have no browser, or if the UI must look identical everywhere. Before committing, build the library on each target OS with the Makefile or GNUmakefile, confirm the browser-discovery path on a clean machine, and check how the current 2.5.0 beta tag relates to the release you plan to pin.
Frequently asked questions
How do I open a WebUI window from C?
Call webui_new_window() to get a window handle, pass HTML to webui_show(), and call webui_wait() to block until the window closes. The README's minimal example does exactly this in four lines of main().
How do I install WebUI on Windows, macOS or Linux?
You build it from the repository rather than installing a package. The README lists mingw32-make for GCC and nmake for MSVC on Windows, make on macOS, and make or make CC=clang on Linux. CMake, Zig, Conan and vcpkg files are also present at the top level.
Does WebUI need a browser installed to run?
Yes. The README's dependency table lists WebUI as needing only a web browser on Windows, Linux and macOS. A cross-platform WebView is available as an optional alternative, but the browser is the default runtime.
How does the frontend talk to the C backend in WebUI?
The page loads webui.js, and communication runs over a WebSocket that the README describes as a fast binary protocol. The library embeds CivetWeb, compiled with USE_WEBSOCKET, to serve the page and carry that traffic.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/webui-dev-webui)