Zebkit packages Chromium's engine as a linkable library for native apps

Chromium as a component you add

Zebkit, an open-source project that has drawn attention on Hacker News, wraps the core of Chromium in a single library that applications link against rather than host. According to the project's README, the library carries Blink, the full V8 JavaScript engine including its JIT tiers, PDFium, FFmpeg and the remaining pieces of the browser engine — while leaving out Chrome's browser shell and Electron's Node-based runtime layer.

The design inverts Electron's arrangement. An Electron application is built inside Electron, on its runtime, its windows and its packaging. Zebkit instead behaves like SQLite: the host program keeps its own process, its main() function and its toolkit, and calls the library where it needs the web. It is driven through two C calls, zebkit_init() and zebkit_pump(), on the application's event loop, and it draws into windows the application supplies — an X11 window, an NSView or an HWND on Linux, macOS and Windows respectively. The API is C, with bindings for Rust, Python and JavaScript.

Benchmarked against Electron

The README publishes comparisons with Electron 45.2.1, all self-reported: 34% smaller, a cold start of 2.3 seconds against 6.6 seconds, and a page loaded in 29% less memory. Node.js is absent entirely — there is no second JavaScript runtime and no IPC routed through one. Application code is native, or JavaScript executed by zebkit-js on the engine's own V8.

Chromium's internals, exported

The project also exposes the engine's own utility layer: 17 C libraries totalling roughly 7,490 functions per platform, with 7,487 identical across all three, published under a zebkit_vendor_ prefix. The list spans SQLite, LevelDB, BoringSSL, zlib, Zstandard, Brotli, ICU, HarfBuzz, libxml2, libwebp, libjpeg-turbo, FFmpeg, dav1d, Opus, libvpx, FreeType and PDFium — so an application does not ship those dependencies twice.

Around the renderer sit several higher-level services. A full PDF toolkit built on PDFium covers rendering, search, annotations, forms, redaction, page editing and signature verification. A 2D drawing header targets the engine's Skia, and a text header targets its HarfBuzz. A media API writes whatever a page plays — a file, MSE/DASH or HLS — to MP4 or WebM exactly as received, with no re-encoding and no second download. Calls from a page into the application travel over the frame's own Mojo channel, with large payloads passed through shared memory instead of base64 text.

Automation and agent support

The whole of Playwright's API — locators, auto-waiting actions, routes, contexts, traces, HAR and video — runs inside the engine itself, without CDP or a Node.js driver. The project claims this is three to ten times faster than Playwright over CDP, with a click completing in 3 to 5 milliseconds instead of 33. Standard Playwright clients can connect unchanged via chromium.connect(). A bundled zebkit-mcp tool additionally exposes pages, PDFs, files, media and native windows as MCP tools for AI agents, within limits an operator sets.

For interface work, zebkit.ui lets JavaScript draw windows, prompts and dialogs using Chromium's views toolkit, positioned as the frame around page content rather than a replacement for it.

Security defaults

According to the README, a page receives no zebkit object unless the application grants one, per view, per origin and per capability, and the origin is determined by the browser rather than the page. The renderer stays sandboxed, and permissions a browser would normally prompt for are not granted automatically. Native hooks in C, Rust, Python and JavaScript let applications intercept permissions, navigation, popups, downloads, certificates, network requests and responses at every stage, and custom URL schemes.

Platforms and maturity

Zebkit tracks Chromium 157.0.8103.38 and is at version 0.4.0. Linux builds target x86-64 with glibc 2.17 or newer and support both X11 and Wayland; macOS builds cover Apple silicon; Windows builds require Windows 10 or newer on x64. Compiling from source needs around 30 GB for the Chromium tree and takes hours on the first run, though prebuilt release archives are available. The project documents remaining gaps, among them differences around Google sign-in.

Why it matters

Embedding web content in desktop software has largely meant accepting Electron's trade-off: a full browser plus Node wrapped around your code. Zebkit proposes the opposite arrangement — keep the native application and add the web as a linked component, with genuine Chrome rendering, the engine's utility libraries thrown in, and automation APIs suited to testing and AI agents. Maintaining an engine build against upstream Chromium is a heavy, ongoing commitment, and the performance figures are the project's own rather than independently verified. Still, as an architectural option for developers who want Chromium without the runtime, it is a notable entry.