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-I50 (the next unclaimed SHA-256 ranks per type, frozen 2026-10-25 before any measurement, rule in pipeline_data/FROZEN_BLIND_I.md); this is its first and only measurement, and every engine was at its latest public release that day. Oxi is second on pixels at 0.903, 0.006 behind ONLYOFFICE (0.909) and ahead of WordCraft (0.885) and LibreOffice (0.864), and reproduces Word’s page count on the most documents: 47 of 50 against ONLYOFFICE’s 42. Document by document the picture is less flattering: ONLYOFFICE is closer to Word on 37 of 50 and WordCraft on 34, while Oxi beats LibreOffice on 30 — Oxi’s mean holds up because its bad documents are less bad, not because it wins the typical one. Charging every page an engine adds or drops as zero, the penalized means are ONLYOFFICE 0.888, Oxi 0.883, WordCraft 0.857, LibreOffice 0.828, Polaris Office 0.813, SILURUS 0.806, GenOffice 0.747, ibisOffice 0.706, eigenpal 0.704, BetterOffice 0.636, OfficeCLI 0.443. Ground truth is Microsoft Word (Microsoft 365 16.0.20430.20182) at 150 DPI, one fresh Word process per document. Polaris Office is driven through its own window (it has no command line); the six English documents it would not export on two attempts count as not rendered.
Word’s saved page breaks. Word writes <w:lastRenderedPageBreak/> where its own render started each page, and Oxi’s parser can read it, which other engines do not. To rule out that hint, the blind-I numbers above were re-run with the same frozen engine on copies with every marker removed (2026-10-28): English 0.903 / 0.883 / 47 of 50 and Japanese 0.905 / 0.899 / 47 of 50, the same as published. Benchmarks now run with the marker hidden by default (OXI_IGNORE_LRPB=1).
English blind set — 50 never-touched documents, per-document mean SSIM vs Word (2026-10-25)
ONLYOFFICEpage count matches Word on 42/50 · v10.0.0 · 49 of 50 rendered
0.909
Oxipage count matches Word on 47/50
0.903
WordCraftpage count matches Word on 41/50 · v0.10.0
0.885
LibreOfficepage count matches Word on 39/50 · v26.8.1.1
0.864
SILURUSpage count matches Word on 41/50 · v0.89.4
0.842
Polaris Officepage count matches Word on 35/50 · v11.115 · 44 of 50 rendered
0.830
GenOfficepage count matches Word on 35/50 · v28cee5ca
0.815
ibisOfficepage count matches Word on 33/50 · v0.8.4
0.783
OfficeCLIpage count matches Word on 14/50 · v1.0.158
0.770
BetterOfficepage count matches Word on 26/50 · v0.4.3
0.767
eigenpalpage count matches Word on 33/50 · v1.9.0
0.756
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, and WordCraft and ibisOffice (Rust office suites that export a PDF from their own command line) on 2026-10-25; every bar is the 2026-10-25 measurement at the latest release 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 jaBlind-I50 (frozen 2026-10-25 before any measurement; the public manifest has no Japanese technical documents left, so those five slots went to the next entries across the other types by the rule declared in advance — all five are forms). Oxi leads on pixels (0.905) by 0.057 over Polaris Office (0.848, which comes within one document of Oxi on page breaks) and 0.074 over LibreOffice (0.831), and is closer to Word than Polaris Office on 40 of 50 documents, than LibreOffice on 43, than WordCraft on 43 and than ONLYOFFICE on 48; it also places the most page breaks where Word does (47/50). Engine rankings do not transfer between languages — ONLYOFFICE is first in English and ninth in Japanese — which is why a blind set is kept per language. Earlier Japanese sets scored 0.842 / 0.802 / 0.802 / 0.857 on the engines of their day; this one is the first above 0.90 — one sample, so the usual ±0.02 applies.
Japanese blind set — 50 never-touched documents, per-document mean SSIM vs Word (2026-10-25)
Oxipage count matches Word on 47/50
0.905
Polaris Officepage count matches Word on 46/50 · v11.115
0.848
LibreOfficepage count matches Word on 41/50 · v26.8.1.1
0.831
WordCraftpage count matches Word on 37/50 · v0.10.0
0.827
GenOfficepage count matches Word on 34/50 · v28cee5ca · 49 of 50 rendered
0.825
SILURUSpage count matches Word on 31/50 · v0.89.4 · 48 of 50 rendered
0.821
ibisOfficepage count matches Word on 41/50 · v0.8.4
0.819
OfficeCLIpage count matches Word on 32/50 · v1.0.158
0.810
ONLYOFFICEpage count matches Word on 38/50 · v10.0.0
0.790
BetterOfficepage count matches Word on 34/50 · v0.4.3
0.785
eigenpalpage count matches Word on 36/50 · v1.9.0
0.768
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 — 215 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.
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-I50 set (frozen and measured 2026-10-25, every engine at its latest release) Oxi scores 0.903 per document and reproduces Word’s page count on 47 of 50, the most of any engine; ONLYOFFICE is slightly ahead on pixels (0.909, 42/50) and LibreOffice behind (0.864, 39/50). On the Japanese blind-I50 set Oxi leads at 0.905, ahead of Polaris Office (0.848) and LibreOffice (0.831), and places the most page breaks correctly (47/50). 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
