A browser-native .docx rendering engine, measured against Microsoft Word — pixel by pixel.
Oxi opens Word documents in the browser with Word-faithful layout. Built from scratch in Rust + WebAssembly, verified page-by-page against Microsoft Word with SSIM. Open source, no server, and your files never leave your device.
English is measured the hard way: a frozen blind benchmark of 50 documents from the public docx-corpus that are never used as fix targets — every score is first-sight generalization, with nothing tuned to the test. Re-measured on 2026-07-29 Oxi scores 0.825 per document (0.800 at its first measurement on 2026-07-19, 0.807 on 2026-07-20) and now matches Word's page count on 48 of the 50 documents — more than any other engine measured, including ONLYOFFICE (41) and LibreOffice (43). On pixel similarity it is still behind ONLYOFFICE (0.902) and LibreOffice (0.876) and ahead of SILURUS (0.776) — the closest architectural peer, a Rust + WebAssembly canvas renderer, which Oxi beats on 36 of the 50 documents. That remaining gap is the English work queue: the set is re-measured as the engine improves. Engines: Microsoft Word (Microsoft 365 16.0.20131.20154) as ground truth, ONLYOFFICE 9.3.1.8, LibreOffice 26.2.1.2, SILURUS @silurus/ooxml 0.72.2 — all rendered at 150 DPI. On 2026-07-27 a fifth engine was added against the same frozen ground truth: BetterOffice (@betteroffice/docx 0.0.4, a new Rust + WebAssembly editor suite first published 2026-07-18), which scores 0.734 with Oxi ahead on 45 of the 50 documents. The same day added a sixth: eigenpal (@eigenpal/docx-editor-react 1.9.0, an Apache-2.0 WYSIWYG DOCX editor that lays out DOM pages via ProseMirror), which opens all 50 and scores 0.739 — Oxi is ahead on 44 of the 50 documents.
English blind set — 50 never-touched documents, per-document mean SSIM vs Word (2026-07-29)
ONLYOFFICEpage count matches Word on 41/50 · v9.3.1.8
0.902
LibreOfficepage count matches Word on 43/50 · v26.2.1.2
0.876
Oxipage count matches Word on 48/50 — best of the six
0.825
SILURUSpage count matches Word on 35/50 · v0.72.2
0.776
eigenpalpage count matches Word on 33/50 · v1.9.0 · measured 2026-07-27
0.739
BetterOfficepage count matches Word on 25/50 · v0.0.4 · measured 2026-07-27
0.734
Top: per-engine mean — the dashed edge marks Microsoft Word itself (1.00). SILURUS is the closest architectural peer (Rust + WebAssembly rendering to a canvas, like Oxi); ONLYOFFICE and LibreOffice are mature native suites; BetterOffice (a Rust + WebAssembly editor suite, v0.0.4) and eigenpal (an Apache-2.0 ProseMirror-based DOM renderer, v1.9.0) are the newest entrants, both measured 2026-07-27 against the same frozen ground truth. Bottom: every dot is one document, with Oxi on the vertical axis; dots above the dashed diagonal are documents where Oxi is closer to Word. The blind set is measured but never fixed against, so this is first-sight generalization, published as-is.
Japanese blind set — 50 never-seen documents
Japanese is held to the same standard as English: a frozen blind benchmark of 50 documents from the public docx-corpus that are never used as fix targets — every score is first-sight generalization, with nothing tuned to the test. At its first measurement (2026-07-21) Oxi scores 0.828 per document and matches Word's page count on 44 of the 50 documents — ahead of LibreOffice (0.816), SILURUS (0.804) and ONLYOFFICE (0.772) on the same documents. Engines: Microsoft Word (Microsoft 365 16.0.20131.20154) as ground truth, LibreOffice 26.2.1.2, ONLYOFFICE 9.3.1.8, SILURUS @silurus/ooxml 0.72.2 — all rendered at 150 DPI. On 2026-07-27 a fifth engine was added against the same frozen ground truth: BetterOffice (@betteroffice/docx 0.0.4), which scores 0.766 and fails to open one of the 50 documents (its parser rejects nextColumn, a standard OOXML section-start type); Oxi is ahead on 38 of the 49 documents both engines open. The same day added a sixth: eigenpal (@eigenpal/docx-editor-react 1.9.0), which opens all 50 — including the nextColumn document BetterOffice rejects — and scores 0.744, with Oxi ahead on 43 of the 50 documents.
Japanese blind set — 50 never-touched documents, per-document mean SSIM vs Word (2026-07-21)
Oxipage count matches Word on 44/50
0.828
LibreOfficepage count matches Word on 41/50 · v26.2.1.2
0.816
SILURUSpage count matches Word on 32/50 · v0.72.2
0.804
ONLYOFFICEpage count matches Word on 38/50 · v9.3.1.8
0.772
BetterOfficepage count matches Word on 29/50 · v0.0.4 · measured 2026-07-27
0.766
eigenpalpage count matches Word on 36/50 · v1.9.0 · measured 2026-07-27
0.744
Top: per-engine mean — the dashed edge marks Microsoft Word itself (1.00). Bottom: every dot is one document, with Oxi on the vertical axis; dots above the dashed diagonal are documents where Oxi is closer to Word. The blind set is measured but never fixed against, so this is first-sight generalization, published as-is.
How the fidelity is earned
100% clean-room: no disassembly or binary analysis. Specifications come only from published standards (OOXML — ISO/IEC 29500 / ECMA-376) and black-box observation of Word's output via the COM API.
Dual font engine: Word's layout inherits GDI's integer-pixel metrics, so Oxi reproduces GDI exactly for .docx — and uses DirectWrite's floating-point metrics for formats without that legacy.
Continuous regression gates: every change is checked against the full corpus — pagination match, element positions, and pixel SSIM.
Most Word-compatible renderers treat Japanese layout as an afterthought. For Oxi it is a measured target.
Kinsoku shori (禁則処理) — JIS X 4051 line-breaking: prohibited line-start/line-end characters, punctuation compression, hanging punctuation (ぶら下げ).
Vertical writing (縦書き) — vertical text sections with right-to-left column flow, plus tate-chu-yoko (縦中横) for horizontal-in-vertical runs.
Ruby (ルビ / furigana), warichu (割注) two-line inline notes, and emphasis marks (圏点).
Character grid (docGrid) — Word's Japanese line-grid and character-pitch model, reproduced to the point.
Hanko (判子) — Japanese digital stamp generation (round, square, oval) with PAdES PDF signatures.
The measurement corpus itself is Japanese-first: ministry regulations, government application forms, and employment contracts — the documents where Japanese layout is hardest.
Technology
Rust + WebAssembly, a format-agnostic intermediate representation, and zero server dependency.
Why it matters now
Public-sector organizations across Europe — France's DINUM directive, Switzerland's Federal Chancellery, Germany's OpenDesk deployments — are actively reducing Microsoft Office dependency in 2026. Every one of those migrations hits the same wall: existing .docx files must keep looking exactly as they do in Word. Oxi's goal is to dissolve that problem with a rendering engine whose Word fidelity is continuously measured, not promised.
Architecture
Client-side only: parsing, layout, rendering and editing run in WebAssembly in your browser. No server infrastructure, no upload, zero hosting cost per document.
Format-agnostic IR:Document → Page → Block (Paragraph | Table | Image) → Run. Neither OOXML nor ODF "owns" the model, so round-trips don't degrade.
Round-trip editing: the original ZIP is preserved and only changed XML text nodes are patched — never rebuilt from scratch.
Open fonts only: no proprietary fonts are bundled; open-licensed fonts are metric-matched to their Microsoft counterparts.
Embeddable: a wasm-bindgen JavaScript API (parse_document, layout_document, edit_docx, …) callable from any web app.
License
Core engine crates are MPL-2.0 (file-level copyleft — embeddable in proprietary products, unlike AGPL). WebAssembly and Python bindings are MIT OR Apache-2.0. Contributions are DCO-only, no CLA.
Frequently asked questions
Is Oxi free to use?
Yes. Oxi is open source — MPL-2.0 core, MIT OR Apache-2.0 bindings — and the web demo is free with no account.
Are my documents uploaded to a server?
No. Everything runs inside your browser via WebAssembly. Files are never transmitted anywhere, which makes Oxi suitable for confidential and personal documents.
How accurate is Oxi compared with Microsoft Word?
Measured with pixel-level SSIM against Word on frozen blind benchmarks — 50 never-seen documents per language that are never used as fix targets. Japanese: 0.828 per document with Word's page count matched on 44/50. English: 0.825 with Word's page count matched on 48/50 — the highest page-count result among the engines measured, while pixel similarity remains behind LibreOffice and ONLYOFFICE there (2026-07-29). See the accuracy section for the comparison charts and methodology.
Which file formats does Oxi support?
Oxi focuses on Word .docx: full page layout and round-trip editing. Reproducing Word's .docx rendering faithfully is the mission — everything else comes after.
Can I embed Oxi in my own product?
Yes. MPL-2.0's file-level copyleft plus permissive bindings mean Oxi can be embedded in commercial and proprietary products.
Does Oxi work offline?
Once the page and the WebAssembly module are loaded, all document processing is local — no network connection is needed to open, render or edit files.
