File Viewer

Uploading a private DOCX just to preview it is awful. I kept running into products that sent the file to a conversion server, or demos that worked from a CDN and then broke inside a private network. I wanted the preview to happen where the file already was: in the browser.

So I built File Viewer.

It gives JavaScript apps one API for 208 file extensions across 25 lazy preview pipelines. Office, PDF/OFD, CAD, STEP, archives, email, diagrams, Markdown, source code, PSD, fonts, media, ebooks, 3D and structured data all enter through the same lifecycle. Each heavy engine loads only when its format is opened. Workers, WASM, fonts and vendor files can be served from your own origin, so an offline or air-gapped deployment does not depend on a public CDN.

The smallest setup is a web component:

npm i @file-viewer/web-full

<file-viewer src="/files/report.docx"></file-viewer>

There are also packages for Vanilla JS, Vue 3, Vue 2, React, React Legacy, Svelte and jQuery. You can use a small component plus selected presets, or choose a Full package when you want all preview engines ready to use. The Vite plugin can detect installed presets and wire them in.

This is useful in an internal admin panel, document system, knowledge base, help desk, archive, OA, engineering portal or any product where "upload it somewhere else first" is a bad answer. The demo requires no account. Pick a sample or paste a file URL and see the real renderer.

I do not want to hide the ugly parts. Office output is not pixel-perfect. Rare fonts, embedded objects, charts and hard pagination can look different from Microsoft Office. Large files are also hard because parsing and rendering spend the user's RAM. A huge archive, spreadsheet or model can slow down or crash a tab. Browser-side preview removes a server dependency. It does not remove browser limits.

File Viewer started in 2022 after I was pushed to build an Office viewer with almost no server capacity. My first plan was to wrap one library. That failed badly. Every format had different Worker paths, WASM rules, fonts and cleanup bugs. I ended up splitting the formats into isolated pipelines and building the shared loading and lifecycle layer around them.

The project is open source. I am still working on fidelity, memory use, deployment paths and strange files from real systems. What breaks first in your app: Office fidelity, browser memory, or Worker/WASM paths?