Silurus/ooxml: Pixel-faithful Office documents, rendered in the browser

Silurus/ooxml has launched as an open-source library that renders Office Open XML documents directly within web browsers, achieving pixel-perfect fidelity. Developed entirely in Rust and compiled to WebAssembly, it supports DOCX, XLSX, and PPTX formats, offering developers a new way to embed Office document viewers into web applications without relying on external viewers or server-side rendering.

The library includes Rust-based parsers for each Office format, which are compiled to WebAssembly for efficient in-browser execution. It uses the Canvas 2D API for rendering, enabling precise layout and styling. The system also supports rendering equations in DOCX and PPTX files through an optional MathJax + STIX Two Math engine, which can be included or omitted to optimize bundle size.

Developers can instantiate viewers for each format, providing their own HTML canvas elements or containers. The library is modular, allowing tree-shaking of features such as the math engine, and supports complex document features like charts, shapes, and equations. It also includes a headless API for server or automated processing, making it versatile for various use cases.

Why It Matters

This development matters because it enables high-fidelity Office document rendering entirely on the client side, eliminating the need for server-side conversion or external viewers. It opens possibilities for integrating Office document previews into web apps, collaborative platforms, and educational tools with pixel-perfect accuracy and full control over rendering and UI. The open-source nature encourages further customization and innovation in in-browser document handling.

Background

Prior to this, most in-browser Office document rendering relied on converting files to HTML or PDF via server-side tools, often sacrificing fidelity or requiring proprietary solutions. Existing JavaScript libraries lacked the pixel-perfect rendering or full feature support, especially for complex layouts and equations. The rise of WebAssembly has enabled more performant in-browser processing, paving the way for projects like Silurus/ooxml.

This project builds on recent advances in Rust-to-WASM compilation and the increasing demand for client-side document handling in web applications, especially as remote work and online collaboration grow.

“Our goal was to create a fully client-side, pixel-accurate renderer for Office documents that can be integrated into any web app without external dependencies.”

— Silurus/ooxml team

What Remains Unclear

It is not yet clear how well the library performs with extremely large or complex documents, or how it handles all edge cases in Office files. Compatibility with newer or heavily customized Office features remains to be tested. Additionally, the long-term stability and community adoption are still developing.

What’s Next

Future developments include expanding support for more Office features, improving performance with larger files, and developing plugins or integrations for popular web frameworks. The team plans to release detailed documentation and encourage community contributions to enhance robustness and feature set.

Key Questions

Can I use Silurus/ooxml in production applications?

Yes, as an open-source project, it is available for integration into production, but users should test thoroughly for their specific use cases, especially for large or complex documents.

Does it support all Office features like macros or embedded media?

No, the current version focuses on core layout, styling, and equations. Support for macros, embedded media, or advanced features is limited or not yet implemented.

How does it compare to server-side rendering solutions?

Silurus/ooxml provides client-side, pixel-perfect rendering without server dependencies, offering more control and interactivity, but may require more initial setup and testing for complex documents.

Is the math engine required for rendering equations?

Rendering equations is optional; including the math engine increases bundle size (~3 MB) but enables equation rendering. It can be omitted for smaller, faster builds where equations are not needed.

Source: Hacker News