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. The current set is blind-C50 (manifest ranks 21-25, frozen 2026-07-29 before any measurement); this is its first pixel measurement, 2026-08-31. Word itself fails to export 2 of the 50, so every engine is scored on the same 48. Oxi reproduces Word’s page count on 48 of 48 — the only engine measured that matches every document, against ONLYOFFICE’s 42 and LibreOffice’s 43. On within-page pixels ONLYOFFICE is 0.005 ahead (0.908 vs 0.903) and LibreOffice is a near-tie at 0.892, Oxi ahead on 25 of 48. Once page-count misses are charged the order widens: penalized means are SILURUS 0.741, eigenpal 0.723, BetterOffice 0.619, GenOffice 0.570, OfficeCLI 0.486, against Oxi’s 0.903. 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.83.1, eigenpal @eigenpal/docx-editor-react 1.9.0, BetterOffice @betteroffice/docx 0.1.0, GenOffice v0.1.0, OfficeCLI 1.0.145 — all at 150 DPI. OfficeCLI is measured with --render html, its own layout engine: its default --render auto delegates to Word on a host that has Word installed, scoring 0.996 against Word because it is Word.
English blind set — 48 never-touched documents, per-document mean SSIM vs Word (2026-08-31)
ONLYOFFICEpage count matches Word on 42/48 · v9.3.1.8
0.908
Oxipage count matches Word on 48/48 — best measured
0.903
LibreOfficepage count matches Word on 43/48 · v26.2.1.2
0.892
SILURUSpage count matches Word on 35/48 · v0.83.1
0.791
eigenpalpage count matches Word on 35/48 · v1.9.0
0.768
BetterOfficepage count matches Word on 26/48 · v0.1.0
0.761
OfficeCLIpage count matches Word on 17/48 · v1.0.145 · own HTML engine
0.753
GenOfficepage count matches Word on 17/48 · v0.1.0
0.740
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) and eigenpal (an Apache-2.0 ProseMirror-based DOM renderer) joined the comparison on 2026-07-27 and GenOffice (Genspark's Apache-2.0 AI office suite) on 2026-08-06; every bar is the 2026-08-31 measurement at the version printed on it, 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 measured to the same standard. The current set is blind-C50 (ranks 16-20, frozen 2026-08-31 before any measurement); this is its first measurement, and the previous Japanese blind set was demoted to the development corpus the same day. Oxi leads on pixels (0.802), but by 0.012-0.015 over SILURUS (0.790) and LibreOffice (0.788) — a modest margin on 50 documents, not a decisive one. ONLYOFFICE places more page breaks correctly (40/50 against Oxi’s 35/50), so Oxi does not lead on both. Engine rankings do not transfer between languages — ONLYOFFICE is first in English and fifth in Japanese, SILURUS fourth in English and second in Japanese — which is why a blind set is kept per language. Two independently frozen sets measured the same day on the same binary (blind-B50 / blind-C50) scored 0.842 and 0.802, matching Word’s page count on 45/50 and 35/50. That 0.040 is set difficulty, not engine change: a single blind number carries about ±0.02.
Japanese blind set — 50 never-touched documents, per-document mean SSIM vs Word (2026-08-31)
Oxipage count matches Word on 35/50
0.802
SILURUSpage count matches Word on 32/50 · v0.83.1
0.790
LibreOfficepage count matches Word on 33/50 · v26.2.1.2
0.788
OfficeCLIpage count matches Word on 22/50 · v1.0.145 · own HTML engine
0.748
ONLYOFFICEpage count matches Word on 40/50 — best measured · v9.3.1.8
0.743
GenOfficepage count matches Word on 10/50 · v0.1.0
0.732
eigenpalpage count matches Word on 35/50 · v1.9.0
0.705
BetterOffice 0.1.0 is absent from the Japanese chart: its English pass completed, but the Japanese pass produced no output at all. Recorded as incomplete rather than estimated.
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.
PowerPoint blind set — 48 never-seen decks
The same discipline, applied to .pptx: 50 decks sampled at random (seed declared before fetching) from the public noxneural/pptx_collection_templates dataset, scored against Microsoft PowerPoint’s own render at 150 DPI — two corrupt files no engine opens are excluded, leaving 48. First measured at 0.679 on 2026-08-13, the renderer reached 0.953 on 2026-08-20 — ahead of LibreOffice (0.913; paired difference +0.040 ± 0.005, |t| = 8.7, Oxi ahead on 44 of the 48 decks) and ONLYOFFICE (0.908) — with every engine matching PowerPoint’s slide count on all 48, every single deck improving over that week, and the worst deck now at 0.880.
PPTX blind set — 48 never-seen decks, per-deck mean SSIM vs PowerPoint (2026-08-20)
Oxislide count matches PowerPoint on 48/48
0.953
LibreOfficeslide count matches on 48/48 · v26.2.1.2
0.913
ONLYOFFICEslide count matches on 48/48 · v9.3.1.8
0.908
Excel — formulas and VBA in the browser
The .xlsx engine ships a dependency-graph formula engine — 61 functions, recalculation diffed against Excel’s own cached results across 285 real workbooks — and a client-side VBA host that runs workbook macros in the browser: Range / Worksheet / Workbook operations, Sort, AutoFilter, Find, Copy/PasteSpecial and WorksheetFunction, 95 members across 11 host objects, each derived from and verified against real Excel COM behaviour (82 scripted A/B comparisons). Macro edits write back differentially — the original ZIP is preserved, and a no-edit save is byte-identical.
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?
Oxi’s layout is measured against Microsoft Word page by page with pixel-level SSIM, on frozen blind benchmarks of never-seen documents that are never used as fix targets. On the English blind-C50 set (first measured 2026-08-31) Oxi scores 0.903 per document and reproduces Word’s page count on 48 of 48 documents — the only engine measured that matches every one; ONLYOFFICE is marginally ahead on pixels (0.908, 42/48) and LibreOffice close behind (0.892, 43/48). On the Japanese blind-C50 set Oxi leads on pixels at 0.802, ahead of SILURUS (0.790) and LibreOffice (0.788), though ONLYOFFICE places more page breaks correctly there (40/50 against Oxi’s 35). Engine rankings do not transfer between languages, which is why a blind set is kept per language. 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.
W
X
