Bez Project Aims to Generate a Web Browser Engine Instead of Hand-Coding One

A project called Bez is testing an unusual premise: that a web browser engine could be generated from specifications and tests rather than built by hand over years by hundreds of engineers.

Today, only a handful of companies can afford to build and maintain a web rendering engine, and that scarcity gives them outsized influence over how the web works in practice. Bez's creators argue that if an engine can instead be generated from the web's written specifications, using the three major shipping browsers — Chromium, Firefox and WebKit — and the Web Platform Tests (WPT) suite as checks, the cost of producing additional engines drops sharply once the generation pipeline is built.

The project has several stated goals beyond simply producing a full browser engine. One is a "tree-shaken" build option: by analyzing a specific site or app, Bez could generate an engine containing only the web features that content actually uses, rather than shipping a complete engine with unused features merely switched off. The team says this would make for smaller, faster, easier-to-embed engines — useful for applications and devices that currently either bundle the whole of Chromium or skip web rendering altogether. Another goal is speed of maintenance: when a specification or test changes, only the affected generated code would need to be regenerated and re-verified, instead of manually rewritten.

Mechanically, the process starts with spec text. A model writes many candidate implementations, each of which is run inside the engine and compared against cached output from Chromium, Firefox and WebKit. Candidates that match are committed as ordinary Rust code; those that don't are discarded.

The project is in an early stage. Measured against the browser-compat-data dataset (version 8.0.4, with 17,259 tracked feature keys) as of September 25, 2026, generated code covers just 0.6% of the overall web platform, with hand-written code covering another 0.3% and various oracle-linked or oracle-only categories covering a further 6.2%. The remaining 93% is unreached. CSS shows the most progress, at 2.5% generated, while HTML, JavaScript, SVG, WebAssembly, HTTP and MathML all remain at 0%.

Foundational pieces — the DOM, style system, box tree and fragment tree — are hand-written and already pass browser-comparison checks. Of nine generated CSS 2.1 layout rules, eight were produced by models and accepted after a three-way vote against the browsers; the ninth, for block height, remains hand-written because no generated candidate outperformed it. Together, these rules pass 227 recipe test cases and 11 usable WPT normal-flow test pages.

The team reports several findings from testing its three-browser comparison approach. Across 705 browser-pair comparisons spanning 235 documents, the engines agreed 699 times; all six disagreements involved deeply nested percentage calculations, and a majority vote consistently flagged Firefox as the outlier. Investigating further, the team traced this to a genuine web-compatibility bug: Firefox's Gecko engine rounds lengths to 1/60 of a pixel, while Chromium's Blink and Apple's WebKit use 1/64 of a pixel, a discrepancy that can cause flex items to wrap only in Firefox or make measured element widths differ by a pixel. The team says its reproductions match previously diagnosed breakage on Slack, the Google Store and Samsung's site, and correspond to an existing Mozilla bug report (bug 1719314).

Beyond layout, the project reports that a stable three-engine majority vote covers 94.8% of WPT's roughly 2.28 million test and subtest results, and that script-observable behavior — traced under a simulated media profile — agrees across 15 of 18 engine pairs, with the three disagreements attributed to genuine platform differences. Testing suites for canvas, WebGL, Web Audio and WebGPU each show different degrees of usability as automated oracles, ranging from roughly 50% to more than 99% depending on the suite and category.

The team also experimented with logic programming, writing CSS margin-collapsing rules in Datalog; the approach matched browser behavior on 1,195 of 1,195 tested offsets and caught a deliberately introduced bug that the standard geometry check missed. More broadly, the project estimates that 55–60% of browser-compatibility entries currently have both a usable automated oracle and generatable specification text, while 8–18% have neither — a rough measure of how much of the web platform this generation approach could plausibly cover.

Open questions the team is still working through include the real cost of building each rule by hand for comparison, how broadly a feature's generated portion should extend, how much of WPT can be exercised without JavaScript, and where code generated from web IDL definitions should end. The project's source material draws on established web-standards resources including the W3C's browser-specs and webref repositories, the web-features and browser-compat-data projects, and WPT itself.