Uploading a private DOCX just to preview it is awful. File Viewer keeps the work in the browser. It maps 208 extensions to 25 lazy preview pipelines for Office, PDF/OFD, CAD, archives, email, diagrams, 3D, media and data. Use it with plain JavaScript, Web Components, React, Vue, Svelte or jQuery. Workers, WASM, fonts and other assets can stay on your own server. It is Apache-2.0. Office fidelity and huge files are still the hard parts.
No reviews yetBe the first to leave a review for File Viewer
Maker
📌
I started this in 2022 after a work request: preview documents entirely in the browser for a consumer app whose backend resources were limited. I expected it to be a narrow internal problem, but the first blog post brought many developers with the same need.
The hardest work has been format compatibility and large-file performance, especially reliable Worker/WASM loading under private and offline deployments. Today it maps 206 extensions across 24 preview pipelines, from Office and PDF/OFD to CAD, archives, email, diagrams, 3D and data.
I’d especially value feedback on engineering formats, everyday documents, large files and deployment friction. Please share sanitized samples or compatibility reports if something does not render as expected.
Report
Would love to see a side-by-side diff view for revisions of Office and PDF docs, since read-only previews are great but comparing two versions without exporting would make internal review workflows way smoother.
Report
Maker
@suna229648 Thanks, Suna. This would be genuinely useful. Read-only preview solves only half of an internal review job if people still have to export both files to compare them. A first version could pair synchronized scrolling with text-level highlights; Office layout changes are the ugly part. I'm keeping this direction in mind.
Report
offline-first is huge for our internal tools, and the fact it just works in the browser without uploading to a server is exactly what we needed. tossed a random ofd file at it and it handled the format i half expected to fail.
Report
Maker
@ceylinrekl61430 Thanks, Ceylin. You actually threw a random OFD at it - that is the best kind of feedback. OFD has been one of the rougher formats, so hearing it worked when you expected it to fail feels great. If you ever find one that breaks, a sanitized sample would help me fix it.
Report
as someone who self-hosts a lot of internal tools, the offline-first approach is genuinely useful. one thing that would push this further for me is a built-in thumbnail caching layer so preview grids in file browsers stay snappy after the first load. the rest looks solid, nice work
Report
Maker
@emrahs64657 Thanks, Emrah. Thumbnail caching is a great call. A file-browser grid makes the missing cache painfully obvious after the first load. I'd rather expose a cache hook than force one storage backend, so hosts could choose memory, IndexedDB, or their own store. I'm going to explore that shape.
Report
Handy for our internal dashboard where we deal with weird legacy file types daily. The self-hosted WASM setup was straightforward, and previewing .ofd and .dwg directly in the browser without round-tripping through a server just works.
Report
Maker
@gozenmasal15969 Thanks, Masal. I'm especially glad the self-hosted WASM setup was straightforward; that part used to be awful. OFD and DWG in one internal dashboard is exactly the messy real-world mix I built this for. If either format breaks, a sanitized sample would be incredibly useful.
Would love to see a side-by-side diff view for revisions of Office and PDF docs, since read-only previews are great but comparing two versions without exporting would make internal review workflows way smoother.
@suna229648 Thanks, Suna. This would be genuinely useful. Read-only preview solves only half of an internal review job if people still have to export both files to compare them. A first version could pair synchronized scrolling with text-level highlights; Office layout changes are the ugly part. I'm keeping this direction in mind.
offline-first is huge for our internal tools, and the fact it just works in the browser without uploading to a server is exactly what we needed. tossed a random ofd file at it and it handled the format i half expected to fail.
@ceylinrekl61430 Thanks, Ceylin. You actually threw a random OFD at it - that is the best kind of feedback. OFD has been one of the rougher formats, so hearing it worked when you expected it to fail feels great. If you ever find one that breaks, a sanitized sample would help me fix it.
as someone who self-hosts a lot of internal tools, the offline-first approach is genuinely useful. one thing that would push this further for me is a built-in thumbnail caching layer so preview grids in file browsers stay snappy after the first load. the rest looks solid, nice work
@emrahs64657 Thanks, Emrah. Thumbnail caching is a great call. A file-browser grid makes the missing cache painfully obvious after the first load. I'd rather expose a cache hook than force one storage backend, so hosts could choose memory, IndexedDB, or their own store. I'm going to explore that shape.
Handy for our internal dashboard where we deal with weird legacy file types daily. The self-hosted WASM setup was straightforward, and previewing .ofd and .dwg directly in the browser without round-tripping through a server just works.
@gozenmasal15969 Thanks, Masal. I'm especially glad the self-hosted WASM setup was straightforward; that part used to be awful. OFD and DWG in one internal dashboard is exactly the messy real-world mix I built this for. If either format breaks, a sanitized sample would be incredibly useful.