Zebkit – Chromium as an embeddable library

Chrome as a library — light, fast, everywhere, and easy. One API on Linux, macOS and Windows. Add it in a few lines. Introduction zebkit is Chromium's engine as one library you link into your own application: Blink, V8 with every JIT tier, PDFium, FFmpeg and the rest of what Chrome is made of, with nothing of Chrome's browser and nothing of Electron's runtime. Your application stays yours, in C, C++, Rust, Python, Go or JavaScript, with its own windows and toolkit. Where it needs the web, it adds a zebkit view; where it needs a PDF, media, compression or crypto, it calls zebkit's API: in C, or through the bindings for Rust, Python, Go and JavaScript (zebkit-js, and zebkit.* in the application's own pages). Integrate it, don't build on it. Electron is a base: an application is built inside it, on its runtime, its windows and its packaging. zebkit is a part: an application adds it, as it adds SQLite, and keeps its process, its toolkit and its way of shipping. It runs inside the application's own event loop (zebkit_init(), zebkit_pump()), and draws in the application's windows, as frames you draw or in a child of a window you give it, an X11 window, an NSView or an HWND (examples/native-host), and gives back the window a page is in for the system's dialogs. Take what you need. Web views, in a window or off-screen with their frames handed to you; a full PDF API; saving what a page plays; your own URL schemes; native UI from JavaScript; Playwright's API and CDP for agents. Use one, or all. The real Chrome engine. Pages see Chromium 157: its user agent and client hints, window.chrome, popups blocked without a click, and nothing of a debugger attached (docs/API.md has what still differs, Google's sign-in among it). Lighter than Electron. Against the latest Electron, 45.2.1: 34% smaller, a cold start in 2.3 s against 6.6, a page in 29% less memory, and the DOM, text layout and JavaScript level (Benchmark). No Node. No second JavaScript runtime and no IPC through one. The application is native code, or JavaScript run by zebkit-js on the engine's V8. Chromium's libraries are yours. 17 C libraries inside the engine, about 7,490 functions on each of Linux, macOS and Windows (7,487 on all three, the rest each system's own), exported under zebkit_vendor_*: SQLite, LevelDB, BoringSSL, zlib, Zstandard, Brotli, ICU, HarfBuzz, libxml2, libwebp, libjpeg-turbo, FFmpeg, dav1d, Opus, libvpx, FreeType and PDFium. You do not ship them twice. PDF built in. A full API on Chromium's PDFium: rendering and tiles, text with layout, search, outline, links, annotations as an editor has them (line endings, cloudy borders, free text with callouts and rich text, stamps, replies and states, measurement, XFDF and FDF), forms, redaction, page editing, merging, attachments, metadata, and signatures checked for integrity; hooks for an application's own annotation kinds, appearances, events with undo, render layers, OCR, fonts, trust and actions. In C, Rust, Python and JavaScript. 2D drawing and shaping. on the engine's Skia and on its HarfBuzz, without shipping either again. Media, saved as it plays. Whatever a page plays, a file, MSE/DASH or HLS, written to MP4 or WebM as it was sent, without re-encoding and without a second download ( ). Bytes as they are. A page's calls to the application go over its frame's own Mojo channel, large ones through shared memory: no base64, the page's JSON handed on as it was written, as fast as Electron's IPC for small calls and faster for large ones. The window around a page, from JavaScript. zebkit.ui draws windows, prompts and dialogs with Chromium's views toolkit: signals, JSX, Tailwind classes, and automation for tests and agents. Rich UI is a page; zebkit.ui is the chrome around it (docs/UI.md). Playwright's API, natively. The whole of Playwright (locators, actions that wait until they can be done, keyboard, mouse and touch, routes, dialogs, downloads, contexts, workers, traces, HAR, video) runs inside the engine, without CDP or a Node.js driver: 3 to 10 times faster than Playwright over CDP, and a click in 3 to 5 ms instead of 33 ( , docs/AUTOMATION.md). Playwright's own clients, in any of its languages, connect to it unchanged with chromium.connect(). Made for agents. tools/zebkit-mcp gives them pages, PDFs, files, media and native windows as MCP tools, over standard input and HTTP, within bounds its operator sets (docs/MCP.md). They can also drive zebkit through Playwright's API or over CDP, Chromium's own DevTools server, headless or windowed. Customise it from your code, down to the desktop. Native hooks decide what the engine does, in C, Rust, Python and JavaScript: permissions, navigation, popups, dialogs, downloads, certificates and client certificates, sign-in, network requests and responses at every stage, settings at run time, your own URL schemes, what a page may call, scripts before the page's own (docs/ROADMAP_HOOKS.md). And everything a page or the engine would show the person or ask of the system goes through the application: the window's frame (system, overlay or none, with the page as the title bar), menus and the context menu, JavaScript dialogs and sign-in, file and device choosers, screen capture, notifications, the tray, the Dock and taskbar, sharing, the system's theme, power and displays (Fit it into the desktop, docs/SYSTEM_INTEGRATION.md). Safe by default. A page has no zebkit object unless the application grants it, per view, per origin and per capability; the origin is the browser's, never the page's word; the renderer stays sandboxed; permissions a browser would ask about are not granted. Quick start Get the engine A package is a directory with the library, the helper, the engine's data and include/. Either unpack a release's archive (zebkit- - .tar.xz from GitHub's releases), or build one: mise run r # dist/release (Linux), dist/release-macos (macOS), dist/release-windows; hours the first time Each archive also holds the tools, built for its system beside the library and ready to run from where it is unpacked: zebkit-run, zebkit-js and zebkit-mcp (.exe on Windows, sandboxed there too). On an Apple silicon Mac with full Xcode installed, scripts/dist.sh release builds the engine locally into dist/release. Then run scripts/example.sh macos-basic to build and launch the C embedding demo in dist/example/Zebkit Embedded Browser.app. Building needs about 30 GB for Chromium's tree (docs/BUILD.md). Below, $PKG is the package directory. Add it to a program you already have zebkit is a library: your program keeps its main() and calls it. This one renders a PDF's first page to a PNG and reads its text, with PDFium and the image encoders inside zebkit, and nothing else to install: #include #include #include /* Your program, your main(): zebkit is just a library it calls. */ int main(int argc, char argv) { char *error = NULL; zebkit_pdf *pdf = zebkit_pdf_open_file(argv[1], NULL, &error); if (!pdf) { fprintf(stderr, "%s\n", error); return 1; } /* The first page as a PNG, at twice its size. */ zebkit_pdf_render_options options = {.scale = 2, .background = 0xffffffff}; int width, height; uint8_t *rgba = zebkit_pdf_render(pdf, 0, &options, &width, &height, &error); size_t size; uint8_t *png = zebkit_image_encode(ZEBKIT_IMAGE_PNG, rgba, width, height, 0, &size, &error); fwrite(png, 1, size, fopen("page1.png", "wb")); /* And its text. */ char *text = zebkit_pdf_text(pdf, 0, &error); printf("%d pages; page 1 says: %.80s\n", zebkit_pdf_page_count(pdf), text); zebkit_free(text), zebkit_free(png), zebkit_free(rgba); zebkit_pdf_close(pdf); return 0; } cc thumb.c -I$PKG/include -L$PKG -l:libzebkit.so.1 -Wl,-rpath,$PKG -o thumb # Linux cc thumb.c -I$PKG/include -F$PKG -framework Zebkit -Wl,-rpath,$PKG -o thumb # macOS ./thumb report.pdf # 2 pages; page 1 says: Quarterly report ... The PDF API, compression, crypto, URLs, image codecs, ICU and the libraries inside the engine (zebkit_vendor_*, FFmpeg's among them) need no engine loop (docs/API.md); only HTTP through the engine's network stack and web pages do. Add a web view Web pages need the engine running. Here the engine runs the loop: the program starts it with zebkit_main() and works in its callbacks. A program with its own loop (GTK, Qt, AppKit, winit) starts it with zebkit_init() and calls zebkit_pump() (examples/native-host). #include #include static void printed(zebkit_view *view, const char *json, const char *error, void *data) { printf("%s\n", json ? json : error); zebkit_quit(); } static void loaded(zebkit_view *view, zebkit_load_event event, const char *url, void *data) { if (event == ZEBKIT_LOAD_FINISHED) zebkit_view_evaluate(view, "document.title", printed, NULL); } static void ready(void *data) { zebkit_view *view = zebkit_view_new("https://example.com/", 1024, 768); zebkit_view_on_load(view, loaded, NULL); } int main(int argc, char argv) { return zebkit_main(argc, argv, ready, NULL); } cc app.c -I$PKG/include -L$PKG -l:libzebkit.so.1 -Wl,-rpath,$PKG -o app # Linux cc app.c -I$PKG/include -F$PKG -framework Zebkit -Wl,-rpath,$PKG -o app # macOS clang-cl /MT app.c /I%PKG%\include %PKG%\zebkit.dll.lib %PKG%\zebkit_sandbox.lib # Windows ./app --remote-debugging-port=9222 # with CDP for Puppeteer and Playwright On Windows the executable takes part in Chromium's sandbox: it links zebkit_sandbox.lib and calls zebkit_win_startup() first in main() (docs/WINDOWS.md). Without unprivileged user namespaces the engine refuses to start and says why: install its helper, or in a container of its own add --no-sandbox (docs/SANDBOX.md). The page and the application The application serves its own pages from a scheme and gives them functions to call; a page has nothing of zebkit unless it is granted. /* The page calls zebkit.app.greet("Ada"). */ static void greet(zebkit_view *view, const char *origin, const char *args_json, zebkit_call *call, void *data) { char answer[256]; snprintf(answer, sizeof answer, "{\"hello\": %s}", args_json); zebkit_call_resolve(call, answer); } /* app://main/... from ./ui, in ranges for media. A real handler refuses "..". */ static void serve(zebkit_request *request, void *data) { char path[1024]; snprintf(path, sizeof path, "ui%s", zebkit_request_url(request) + sizeof "app://main" - 1); zebkit_request_respond_file(request, path, NULL); } static void closed(zebkit_view *view, void *data) { zebkit_quit(); } static void ready(void *data) { zebkit_view *view = zebkit_view_new("app://main/index.html", 1024, 768); zebkit_view_grant(view, "app://main", ZEBKIT_ALLOW_APP | ZEBKIT_ALLOW_PDF, NULL); zebkit_view_bind(view, "greet", greet, NULL); zebkit_view_on_close(view, closed, NULL); } int main(int argc, char argv) { zebkit_scheme_register("app", ZEBKIT_SCHEME_STANDARD | ZEBKIT_SCHEME_SECURE | ZEBKIT_SCHEME_FETCH); zebkit_scheme_handle("app", serve, NULL); return zebkit_main(argc, argv, ready, NULL); } In the page, every call is a promise and bytes are Uint8Arrays: const reply = await zebkit.app.greet('Ada'); // the application's function const pdf = await zebkit.pdf.open(await (await fetch('report.pdf')).bytes()); const rgba = await pdf.render(0, {scale: 2}); // a page as pixels const hits = await pdf.search('revenue'); const packed = await zebkit.compress('zstd', bytes, 19); const hash = await zebkit.crypto.digest('SHA-256', 'abc'); Fit it into the desktop Each thing the engine would show the person, or ask of the system, has a default that works and a function of the application's that replaces it. Nothing reaches the system without a decision the application can take; without a function, a page gets what a careful browser gives it, and nothing at all where a browser would ask. import zebkit zebkit.scheme_register("app") # served by a scheme_handle(), as in the C example above zebkit.init(["app"]) # The page is the title bar: the window's buttons over it, dragged by its CSS. view = zebkit.View("app://main/index.html", 1000, 700, options={ "frame": "overlay", "controls": {"height": 40, "color": "#1b1d2a", "symbolColor": "#ffffff"}, "dragRegions": {"source": "css", "origins": ["app://main"]}}) # The application's menu bar (macOS) and keys, with state that changes in place. zebkit.app_set_menu([{"title": "File", "items": [{"title": "Autosave", "id": "autosave", "checked": True}]}], lambda item: zebkit.app_update_menu_item(item, checked=False)) # A tray icon, the Dock's or the taskbar's badge, and the page's notifications as the application's. tray = zebkit.Tray(open("icon.png", "rb").read(), "My application") zebkit.app_set_badge("3") zebkit.on_notification(lambda event: print("show in my own UI:", event)) # What a page asks for: a USB device, a screen to capture, a colour, a share. view.on_device_chooser(lambda request: request.respond(request.metadata["devices"][0]["id"])) view.on_media_access(lambda request: request.respond(True, None, "view")) view.on_share(lambda request: request.respond(True)) # The system: its theme and its changes, the session's lock, the screens. zebkit.on_environment_changed(lambda env: print("dark" if env["colorScheme"] == "dark" else "light")) zebkit.on_power_event(lambda event: print(event["event"])) # suspend, resume, lock, unlock print(zebkit.displays()) docs/SYSTEM_INTEGRATION.md has each surface, its default, its status on each system and why; docs/API.md has the calls in the four languages; examples/custom-titlebar is a window whose title bar is the page. Rust zebkit on crates.io, with zebkit-build to put the engine beside your program; the build downloads the engine for your system once and checks its SHA-256. [dependencies] zebkit = "0.4.0" [build-dependencies] zebkit-build = "0.4.0" // build.rs: puts the engine beside the executable fn main() { zebkit_build::bundle(); } // main.rs fn main() { std::process::exit(zebkit::run(|| { let view = zebkit::View::new(Some("https://example.com/"), 1024, 768); view.grant("https://example.com", zebkit::Allow::APP, None); view.bind("greet", |call| { let answer = format!("\"hello, {}\"", call.args_json()); call.resolve(&answer) }); view.on_close(zebkit::quit); })); } ZEBKIT_DIR points the build at a package (bindings/rust/README.md). Python zebkit on PyPI is the binding; the engine is the archive for your system from the releases of the same version, with ZEBKIT_DIR pointing at it: pip install zebkit export ZEBKIT_DIR=/path/to/zebkit-0.4.0-x86_64-unknown-linux-gnu import zebkit # pure Python on ctypes: nothing to compile def ready(): view = zebkit.View("https://example.com/") view.grant("https://example.com", zebkit.ALLOW_APP) view.bind("greet", lambda name, origin: f"hello, {name}") zebkit.main(ready) # the engine is found in $ZEBKIT_DIR Go bindings/golang, on cgo: views, pages calling Go functions, the application's schemes, the page hooks and the system's services, on Linux and macOS. Build with the engine's headers and library: go get github.com/ikey4u/zebkit/bindings/golang@main export CGO_CFLAGS="-I$ZEBKIT_DIR/include" CGO_LDFLAGS="-L$ZEBKIT_DIR -Wl,-rpath,$ZEBKIT_DIR" os.Exit(zebkit.Main(func() { view := zebkit.NewView("", 1024, 768) view.Grant("https://example.com", zebkit.AllowApp, "") view.Bind("greet", func(call *zebkit.Call) { call.Resolve(fmt.Sprintf("\"hello, %s\"", call.Args)) }) view.OnClose(zebkit.Quit) view.Load("https://example.com/") })) JavaScript, without Node zebkit-js runs an ES module on the engine's V8, for applications written in JavaScript, with views, the same APIs, and native windows: // zebkit-js main.mjs const view = new zebkit.View('app://main/index.html', {width: 1024, height: 768}); view.grant('app://main', ['app', 'pdf']); view.bind('save', async (name, text) => { await zebkit.fs.writeFile(`${zebkit.args[0]}/${name}`, text); return {saved: true}; }); view.on('close', () => zebkit.quit()); // zebkit-js examples/ui/todo.mjs: a window of native widgets, styled with // Tailwind's classes and kept up to date by signals (an excerpt) const {h, signal, computed, For, window} = zebkit.ui; const [tasks, setTasks] = signal([]); const done = computed(() => tasks().filter((t) => t.done).length); const Task = (task) => h('view', {class: 'flex-row items-center gap-3 p-3 rounded-xl bg-[#141a2e]'}, h('button', {class: 'w-8 h-8 p-0 rounded-full bg-[#7c5cff] text-white', onClick: () => toggle(task)}, task.done ? '✓' : ''), h('text', {class: 'grow text-[#e6e8f2]'}, task.text)); window({title: 'Today', width: 460, height: 680}, () => h('view', {class: 'flex-col gap-4 p-6 bg-[#0b1020]'}, h('text', {class: 'text-3xl font-bold text-white'}, 'Ship something great'), h('text', {class: 'text-sm text-[#8a91aa]'}, () => `${done()} of ${tasks().length} done`), h(For, {each: tasks}, Task))); Agents Playwright's API runs inside the engine (docs/AUTOMATION.md): every command of Playwright's protocol, in the application's process, with no CDP and no Node.js. From C it is one call, zebkit_automation_call(view, "Frame.click", "{\"selector\": \"#go\"}", done, data); Python has it with Playwright's names: import zebkit from zebkit.automation import Page, expect, run async def test(): page = Page() await page.goto("https://example.com/") await expect(page).to_have_title("Example Domain") await expect(page.get_by_text("documentation examples")).to_be_visible() await page.screenshot(path="example.png") zebkit.quit() zebkit.main(lambda: run(test()), ["python", "--headless"]) Playwright's own clients, its test runner and its other languages included, connect to the engine's Playwright endpoint unchanged: tools/zebkit-run --headless --playwright-port=0 # prints "Playwright listening on ws://127.0.0.1: / " const browser = await chromium.connect('ws://127.0.0.1: / '); const page = await (await browser.newContext()).newPage(); Agents and tools that speak CDP drive zebkit as they would drive Chrome: tools/zebkit-run --headless --remote-debugging-port=9222 https://example.com/ Any CDP client connects to http://127.0.0.1:9222. An MCP client gets the engine's capabilities as tools from tools/zebkit-mcp, a separate program, with file access and origins denied until its operator grants them (docs/MCP.md): ZEBKIT_DIR= cargo build --release --manifest-path tools/zebkit-mcp/Cargo.toml # or the archive's zebkit-mcp --allow-origin https://example.com --allow-write ~/agent-files # on standard input and output zebkit-mcp --http 8931 --allow-origin '*' # on 127.0.0.1, with a token The examples mise example:linux:basic # examples/window.c: a browser window mise example:rust:window # the same in Rust mise example:ffmpeg # examples/ffmpeg.cpp: a library inside the engine (cd examples/gpui-browser && cargo run --release) # a tabbed browser in GPUI-KIT Benchmark Against the latest stable Electron, 45.2.1 (Chromium 156), measured the same way: one harness, the same pages, two thin hosts that do the same thing, every process counted, medians of 5 to 11 runs taking turns, Linux x86-64, 2026-11-06 and 07 (scripts/electron-compare.sh, docs/reports/electron-compare.md). Size. zebkit keeps the whole web platform applications use: HTML, CSS, JavaScript with every JIT tier, WebAssembly, WebGL, media with H.264 and AAC, HTTP/3, PDF. Speed. Chrome's own profile-guided optimization reaches Blink because zebkit is built with CFI as Chrome is; every speed change is kept only when it gains more than it costs in size (docs/SIZE_AND_SPEED.md). Where Electron is ahead: one process fewer a page, and memory on two of the ten sites, YouTube and The Verge, where advertising and video decide. How each number is made: docs/SIZE_AND_SPEED.md. The same Playwright commands three ways, headless, medians (docs/reports/automation-bench.md, scripts/automation-bench.sh): zebkit's API, in-process: your program calls the command through , Python's zebkit.automation or Rust's zebkit::automation; it runs inside the engine, with no Node.js and no protocol. Your Playwright scripts, connected to zebkit: Playwright's own Node.js client, unchanged, with chromium.connect() to zebkit's endpoint; its test suite (v1.64.1) passes 4,046 of its tests there, Chrome 4,196 (docs/AUTOMATION.md, section 7). Playwright with Chrome: Playwright as usual, over CDP. Why it is faster: one call in the renderer where Playwright's server makes several round trips over CDP, no JSON between processes, no Node.js process (Playwright's alone reached 175 MiB); and the frames a click's checks wait for are made at once instead of at 60 Hz on a page without a display. A screenshot is 2.7 times faster: the fresh frame it takes is made at once instead of at the next 60 Hz tick, the PNG is deflated at level 1 with the Up filter (2 ms where Chrome's default level takes 13, for 59 KB instead of 40 KB on this page), and the picture's shared memory is made in one call instead of a page fault at a time. What is left of the 12 ms is the page's frame (4 ms), copying the picture out of the compositor (4 ms) and encoding it (4 ms). The pixels themselves, with no encoding (zebkit_automation_screenshot_pixels(), zebkit's own), take 9 ms. Over CDP zebkit does what Chrome does: frames at 60 Hz, Chrome's PNG. Reference Documentation Repository upstream/ (Chromium's tree, about 30 GB), out/, dist/ and .cache/ are generated and not tracked. zebkit is Chromium plus a small patch set (patches/), built from source. Where Chromium lacks something an application needs, zebkit patches Chromium rather than working around it (docs/BUILD.md). License zebkit is free software under the GNU Lesser General Public License, version 2.1 or (at your option) any later version: LICENSE. Applications of any license, open or closed, can use it as a library. The engine contains Chromium and the libraries it uses (Blink, V8, Skia, PDFium, FFmpeg in its LGPL configuration, ICU, SQLite, BoringSSL and others), each under its own license. Every release archive carries LICENSE, a NOTICE that says where its source is, and THIRD_PARTY_NOTICES.txt with every third-party license text. docs/LICENSING.md says what an application that ships zebkit has to do. Contributions are accepted under the same license: by sending a pull request you agree that your contribution is licensed under the LGPL 2.1 or later, as the rest of zebkit.