miniblink49: a single-file Chromium browser widget for embedding HTML UI in C++ apps

What miniblink49 solves, and who it is actually for

Embedding a web view in a native Windows application usually means pulling in the full Chromium build, which is large and awkward to redistribute, or using the older wke and libcef libraries. The README frames miniblink as the replacement for both: an open source, one file, small browser widget base on chromium, with a pure C interface so that a few lines of code create a browser control. The stated audience is developers writing C++, C# or Delphi applications that need HTML UI without a full browser stack.

The feature list is unusually specific about what that buys you. There is a headless mode described as suitable for web crawlers, network resource interception that can replace any resource on any site with a local file, a switch that turns off cross-domain restrictions, and support for Windows XP and NPAPI. Those are not features a modern Electron-style runtime offers, and they explain why someone would pick an older kernel on purpose. The repository topics list blink, chromium, electron and nodejs, and the README states an embedded Nodejs so the widget can run electron content.

One thing to read carefully: this repository holds the older 49 kernel. The README says the 108 kernel was open sourced in Huawei's openEuler system under the liteview project, and that a 132 kernel is coming. If you need a newer engine, this is the wrong checkout, and the README says so before anything else.

The C interface and the wkeWebView lifecycle

The mechanism is a C API exported from the library, with an opaque handle type named wkeWebView standing in for the browser instance. The README's smallest example creates a borderless transparent window and loads a URL, which tells you the window creation and the navigation are separate calls rather than one constructor.

// 无边框窗体 borderless window
wkeWebView window = wkeCreateWebWindow(WKE_WINDOW_TYPE_TRANSPARENT, NULL, 0, 0, 640, 480);
wkeLoadURLW(window, L"miniblink.net");

The first argument selects the window type, the second is a parent window handle, and the four numbers are position and size. Because the interface is plain C, the same functions can be bound from C# or Delphi without a C++ ABI problem, which is the practical reason the README lists those languages as first-class callers rather than as an afterthought.

The repository layout supports the same reading. Alongside the expected Chromium directories (base, cc, content, gin, gpu, net, skia, third_party) there is a wke directory, a wkexe directory, and an mbvip directory, plus several parallel v8 directories named v8_4_5 through v8_7_5. Shipping multiple V8 versions side by side suggests the project keeps older engine combinations buildable for callers who cannot move, which is consistent with the Windows XP and NPAPI claims. It also means the tree is large and heterogeneous; this is not a small codebase even though the shipped artifact is described as one file.

Installing miniblink49 from the release SDK

The README does not give a build-from-source install. It says compiling yourself is not recommended, and points to the releases page for the compiled SDK, noting that demo_src inside that archive is a complete example. A second option is the mb-demo repository. The releases list shows dated builds such as 20251212, 20250928 and 20250717, so the practical install step is choosing an archive rather than running a package manager.

Once the SDK is unpacked, a first real use is the two-call window above. The header files shipped with the archive define the exported names, and the README's snippet is the shape to expect: create the window, then load a URL. The parent handle is NULL in the example, which produces a top-level window rather than a child of an existing form.

wkeWebView window = wkeCreateWebWindow(WKE_WINDOW_TYPE_TRANSPARENT, NULL, 0, 0, 640, 480);
wkeLoadURLW(window, L"miniblink.net");

What you should see is a 640x480 borderless window rendering the site. If you are hosting the widget inside an existing application instead, the parent handle argument is where your window handle goes, and the window type constant is where you choose a normal frame over a transparent one. The README does not document the full set of WKE_WINDOW_TYPE values in the text given here; the API documentation at miniblink.net/views/doc/index.html is the place it sends you for that.

There is no npm, cargo or apt step, and no version pinning mechanism beyond the release tag you download. Treat the archive as your dependency.

The build-breakage warning is a real constraint

The most honest sentence in the README is the one about compilation. It states that because there are many updates every day, the author cannot guarantee every commit compiles, and asks that build errors not be reported. Whatever you think of that as a maintenance policy, it has a direct consequence: the master branch is not a supported build target. If your process requires reproducible builds from source, this project does not offer one, and the README does not describe a rollback procedure, a compatibility matrix, or a stable branch for embedders.

The second constraint is the kernel version. This repository is the 49 branch. For anything that depends on recent web platform behaviour, 49 is old, and the README's own answer is to look at the 108 kernel in openEuler's liteview or wait for 132. That is a redirect, not a solution inside this repository.

The third is the support model. Help is routed to a forum that requires registration plus manual approval via QQ, a WeChat group, a Telegram group, two QQ groups, email and GitHub issues. That is a lot of channels, and several of them are chat rather than searchable issue trackers. For a team that needs an audit trail for vendor questions, the forum approval step and the chat groups are a poor fit compared with a public issue queue.

None of this makes the project abandoned. The last push was on 2026-05-12, and dated releases continue through 20251212. It does mean you are consuming a snapshot, not a release train.

miniblink49 compared with Electron and with the newer kernels

The README's own comparison is to electron, and it is a size argument rather than a feature argument. It describes mini-electron as a separate project built on miniblink whose goal is a smaller electron runtime, and states the packaged output is around 6 MB. Electron's approach is to ship a Node.js runtime and a Chromium runtime together and let you write the whole application in JavaScript. miniblink's approach is the inverse: your application stays native, and the browser is a widget you call into through a C API. You keep your existing C++ or Delphi codebase and your existing packaging, and you accept an older engine.

The comparison inside the family matters more. The 108 kernel is described as a strategic collaboration with Huawei and is open sourced in openEuler as liteview. If your target is Linux, or you need a newer Blink, that project is the relevant one, not this repository. The 132 kernel is described as coming soon, with the releases page already hosting executables and headers for it. So the honest framing is that miniblink49 is the legacy branch of a family, kept for callers who need the 49 behaviour, Windows XP, or NPAPI.

Against wke and libcef, which the description names as the things being replaced, the difference the README emphasises is the single-file distribution and the pure C surface. That is the whole pitch, and it is a narrow one.

Licence and the cost of staying on a prebuilt SDK

The repository is Apache-2.0, which is permissive and generally straightforward for commercial embedding. The README does not discuss licence obligations for the bundled third-party components, and the tree contains 3rdlib, third_party, skia, v8 and multiple node-related directories. Chromium-derived codebases typically carry additional notices, so the Apache-2.0 file at the repository root is the starting point for a licence review, not the whole answer. That is a question for your own legal review, not something this article can settle.

Upgrade cost is the practical issue. Because the README tells you to download prebuilt binaries and warns that source builds may fail, upgrading means swapping an archive and re-testing your integration against the new exports and headers. There is no documented deprecation policy, no changelog format described in the README, and no stated support window for a given kernel version. The release titles are dates and short notes, for example a 250730 build described as fixing many bugs and adding IPv6 support. That is enough to know a release exists and roughly what changed, and not much more.

If your application has a long support life, budget for the possibility that you cannot move forward without moving to the 108 or 132 kernel, which means a different integration surface and possibly different platform support.

Editorial conclusion

Adopt miniblink49 if you are shipping a Windows desktop application that needs an embedded HTML view, you want a C interface you can call from C++, C# or Delphi, and you can work with a prebuilt SDK instead of building Chromium yourself. Do not adopt it if you need a current Blink engine, a documented rollback path, or a project whose build you can reproduce from the repository, because the README says the checked-in kernel is the older 49 branch, that compiling is not recommended, and that build breakage is expected during daily updates. Before committing, verify which release archive matches your compiler and architecture, confirm the exact exported function names against the header files inside that archive, and check whether the newer 108 or 132 kernels fit your target platforms better.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. weolar/miniblink49 on GitHub