Zebkit – Chromium's engine as a library you link, not a runtime you live in

Open-source developer ikey4u launched Zebkit 0.4.0, a framework that packages the Chromium engine into a single linkable C library instead of an application base like Electron, as detailed in github.com's report. Built directly on upstream Chromium 157.0.8103.38, the library bundles the Blink layout engine, V8 with all JIT tiers, PDFium, and FFmpeg, stripping away Chrome's browser chrome and eliminating Node.js. Applications written in C, C++, Rust, Python, or JavaScript can retain their existing entry points, native event loops, and UI toolkits, calling Zebkit functions only where they require web rendering, PDF tooling, or multimedia processing.

This breakdown covers the technical architecture, resource metrics, exported internal toolsets, and embedded automation interfaces shipped in the initial release. It is designed for desktop software engineers, tool builders, and systems developers who want web layout or Chrome subsystems without inheriting Electron's packaging overhead, multi-process IPC runtime, or duplicated C dependencies.

01Standalone library integration versus application runtimes

Zebkit operates as an importable library rather than an enveloping framework. Instead of structuring an application inside a host environment, developers keep their standard main function and initialize the engine using zebkit_init and zebkit_pump inside their existing event loops. Web pages render directly into application-owned native surfaces, including X11 windows, NSView containers on macOS, and HWND handles on Windows, or into off-screen memory buffers handed directly to the host.

By bypassing Electron's Node.js runtime and inter-process communication layers, host applications communicate with web frames through Mojo channels or shared memory buffers. Small function calls match Electron IPC throughput, while larger payloads pass without base64 serialization. Pages run inside a sandboxed renderer where the zebkit object is withheld by default unless an application explicitly grants capabilities per origin and view.

02Electron performance benchmarks and platform targets

Benchmarked against Electron 45.2.1, Zebkit achieves a 34 percent smaller binary footprint, cold starts in 2.3 seconds compared to 6.6 seconds, and consumes 29 percent less memory when rendering pages. The underlying DOM, text layout engine, and JavaScript execution speeds remain identical to standard Chromium builds. Rendered web pages report Chromium 157 user-agent strings, client hints, and standard window.chrome properties without flagging connected debuggers.

The engine compiles across three primary desktop targets, distributed as release archives containing library binaries, helper executables, and header files. Linux systems require x86-64 hardware with glibc 2.17 or newer, supporting X11 and Wayland via libzebkit.so.1 and zebkit-helper. Apple silicon macOS environments use Zebkit.framework, while Windows 10 or newer x64 systems use zebkit.dll and zebkit-helper.exe cross-compiled from Linux.

03Exported vendor libraries and PDFium services

The shared library directly exports 17 internal Chromium C libraries containing approximately 7,490 functions under the zebkit_vendor_* namespace, with 7,487 identical symbols across all three supported operating systems. Exposed dependencies include SQLite, LevelDB, BoringSSL, zlib, Zstandard, Brotli, ICU, HarfBuzz, libxml2, libwebp, libjpeg-turbo, FFmpeg, dav1d, Opus, libvpx, FreeType, and PDFium. Host applications can use these embedded libraries directly without bundling duplicate binary dependencies.

Embedded subsystems like PDF processing, image codecs, ICU data, and crypto utilities run independently without requiring an active browser event loop. The integrated PDFium API enables page rendering, text extraction, search, annotations with rich-text callouts, form handling, redactions, attachments, and cryptographic signature validation. Developers can also access Skia 2D drawing via canvas.h and HarfBuzz shaping through text.h directly from host code.

04Media capture and native automation interfaces

Multimedia content played inside a page, whether from direct files, DASH streams, or HLS manifests, can be written directly to MP4 or WebM containers on disk via media.h without re-encoding or making secondary network requests. For desktop interface rendering, the zebkit.ui module uses Chromium's views toolkit to build native windows, prompts, and dialogs using signals, JSX, and Tailwind styles driven from JavaScript.

The framework embeds the complete Playwright automation API inside the engine itself via automation.h. Because it runs natively without routing through Chrome DevTools Protocol or an external Node.js driver, actions execute three to ten times faster than standard Playwright implementations, registering clicks in 3 to 5 milliseconds rather than 33 milliseconds. Existing Playwright client libraries in any supported language can connect to the running instance using chromium.connect.

05Agent tooling and native system hooks

For autonomous systems, the included tools/zebkit-mcp utility exposes pages, PDFs, filesystem handling, media operations, and native windows as Model Context Protocol tools over standard input and HTTP within operator-defined constraints. Agents can also operate Zebkit through the embedded Playwright engine or through a standard headless or windowed Chromium DevTools Protocol server instance.

Host software controls engine behavior through native hooks available in C, Rust, Python, and JavaScript. These callbacks intercept permission grants, navigation sequences, popups, authentication challenges, and network requests at each lifecycle phase. Applications also govern desktop integration points, including window framing, context menus, system tray icons, Dock and taskbar behaviors, native sharing targets, and display power settings.