The first DOCX demo looked great.
One page. One font. A small table. No headers. No section breaks. I thought the hard part was done.
Then a customer sent a real contract.
It had missing fonts, nested tables, merged cells, numbered clauses, headers, footers, page breaks, and a signature block that had to stay in the right place. Our clean demo became useless in seconds.
That failure changed how I think about Office preview.
A file that opens is not a file that renders correctly
Parsing the ZIP package is the easy part of DOCX. The ugly work starts after that.
You need to answer questions such as:
- Which font metrics should be used when the original font is missing?
- Does a section break create a new page or only change layout rules?
- What happens when a table is wider than the page?
- How do floating images interact with text?
- Where does a paragraph split when line height and font fallback both change?
A browser can display the text and still get the document badly wrong.
The same trap exists in every Office format.
Old DOC and XLS files use binary structures that are nothing like DOCX and XLSX. PPT and PPTX need different readers. A huge spreadsheet may parse correctly and still freeze the tab when the renderer creates too many cells.
So I stopped treating “Office preview” as one feature.
We split the problem into real pipelines
The commercial build has dedicated paths for DOC, DOCX, PPT, PPTX, XLS, and XLSX. The rough flow is:
file bytes
-> format probe
-> format-specific input guard
-> dedicated parser
-> normalized document model
-> layout and browser renderer
The protected distribution keeps parser entry points behind a small WASM license gate. Workers and WASM assets are served from the same origin. That matters for private networks, strict CSP rules, and deployments with no public internet access.
The gate is deliberately boring:
signed license -> WASM verification -> viewer token -> parser entry
It does not make rendering better. It gives a business deployment a clear delivery boundary without pushing document bytes to our server.
The open-source and commercial paths should not pretend to be the same
I maintain an open-source File Viewer for broad browser-side preview. It covers many formats and is the right answer for a lot of products.
But broad support and high Office fidelity are different jobs.
The open-source path is great when the product needs fast preview across many file types and can accept layout differences. The commercial Office path exists for teams that need private deployment, source delivery, legacy Office support, and someone responsible when a release breaks.
Hiding that difference would be dishonest.
Our test files got uglier on purpose
Pretty samples produce pretty lies.
The useful test set contains files that are unpleasant:
- a contract with several section changes;
- a DOC file saved by an old Office version;
- a spreadsheet with merged regions, charts, frozen panes, and a large used range;
- a deck with custom fonts and shapes positioned outside the normal slide box;
- files with missing fonts;
- files that are valid but unusually large.
We compare structure, page flow, cell position, and failure behavior. A renderer must also fail clearly. A blank page or a tab that spins forever is worse than an honest error.
Browser-side preview still has limits
This is not Microsoft Office rebuilt in JavaScript.
Font substitution can move text. Rare drawing objects can look wrong. Very large files can consume enough memory to freeze the tab. Some products should still use server-side conversion for the hardest documents.
The useful question is not “Can the browser render Office files?”
It can.
The real question is where your product draws the line between instant local preview, high-fidelity browser rendering, and server conversion.
I built Flyfish Office Preview for the middle path: higher Office fidelity, private deployment, and no forced upload to our server.
You can test the current demo here:
What breaks first in your product: pagination, legacy formats, missing fonts, or spreadsheet memory?
Top comments (0)