File Viewer: browser-native Office, PDF and CAD preview without a conversion server

The problem File Viewer targets: internal documents that cannot be uploaded

The README opens with a blunt framing: uploading a private DOCX or DWG just to preview it is awful. That is the whole pitch. The project is aimed at internal web applications, the kind that sit behind a login and hold contracts, drawings, spreadsheets or scanned PDFs that are not allowed to leave the corporate network. The common workaround for those apps is a SaaS converter or a preview microservice per format, and both add a data path the security team has to approve.

File Viewer's answer is to move the parsing and rendering into the browser. The README states that files are parsed and rendered in the browser whenever the format allows it, and that runtime code, renderers, Workers, WASM and vendor assets can all be hosted inside your network. So the audience is front-end and platform engineers building document preview into an existing product, not end users looking for a file-opening utility. The topic list on the repository confirms the intent: self-hosted, private-deployment, offline-first.

That positioning also explains the framework matrix. A team that already has a Vue 2.6 admin panel and a team that just started a React 19 app both need the same viewer, and neither wants to rewrite the host app to get it.

How the rendering path works: renderers, capabilities and presets as separate packages

The repository is a pnpm workspace, and the root package.json shows the build order explicitly: core, then renderers, then capabilities, then presets, then components, then tools and thumbnail, then examples and demo. That layering is the architecture in one line. `@file-viewer/core` holds the shared concepts, the renderer and capability packages hold format-specific work, the presets decide which of those get bundled together, and the component packages wrap the result for each framework.

The README describes the loading behaviour as lazy: PDF, CAD, Typst, archives and other heavy capabilities load by format instead of inflating the first screen. In practice that means a page that only ever shows a PDF does not pay for the CAD pipeline, provided you pick packages that reflect that. The project offers a Standard profile, exact renderer selection, and what it calls the Full compatibility package for existing applications. The npm table splits every framework into a light package and a `-full` package, for example `@file-viewer/react` against `@file-viewer/react-full`.

One API detail is worth pausing on. The Web Component entry point exports `mountViewer` and takes a DOM element plus an options object, while the React package exports a `FileViewer` component that takes the same `url` and `filename` props. The README claims one component API with the same source, lifecycle, toolbar, search, zoom, print and export concepts across formats. The consistent option names across the two examples are the visible evidence for that claim; the rest of the API surface is documented elsewhere, not in the README.

Installing File Viewer and previewing a first PDF

The README gives two entry points. For a new project, the CLI scaffolds one; for an existing application, it integrates into the `package.json` you already have. The README says the CLI detects the framework and package manager, shows the exact packages and asset work before writing, and keeps heavy formats explicit. That last part matters: the tool does not silently pull in every renderer.

# New project
npm create file-viewer@latest my-viewer

# Existing project
npx file-viewer-cli@latest add .

Manual installation is also supported, and it is the faster way to see what the components actually do. For a React 18 or 19 app, the README shows the full package:

npm install @file-viewer/react-full

import { FileViewer } from '@file-viewer/react-full'

export function Preview() {
  return <FileViewer url="/documents/handbook.pdf" />
}

Render that component with a PDF served from your own origin and you should get the viewer mounted in place, with the toolbar, zoom and print controls the README lists among the shared concepts. If you are not on React, the equivalent packages are `@file-viewer/vue3-full` for Vue 3, `@file-viewer/web-full` for vanilla or Web Component use, plus Svelte, jQuery, and the `react-legacy` and `vue2.7`/`vue2.6` variants for older codebases. The vanilla path uses `mountViewer(document.querySelector('#viewer'), { url: '/documents/handbook.pdf', filename: 'handbook.pdf' })`, which is the closest thing to a minimal example in the README.

Note what the README does not give: the asset copying step. It says the CLI shows the asset work before writing, and the build scripts include a `file-viewer-copy-assets` tool, so assets are a real part of setup. The README does not spell out the manual asset layout, so read the CLI guide before wiring this by hand.

Where File Viewer is the wrong tool

The obvious limitation is scope. File Viewer previews files; it does not edit them, and the README never claims otherwise. If your users need to change a DOCX and save it back, this is not the component.

The second limitation is the asset story. The project's selling point is that Workers, WASM, fonts and vendor assets can stay on your network, but that is also the cost. You are responsible for serving those files from your own origin, and the README points to the CLI and the documentation for the details rather than listing them. A team expecting a single npm install to be production-ready will be surprised by the extra hosting step.

The third is the light versus full split. Choosing a light package means some formats will not render until you add the corresponding renderer, and the README does not enumerate which format lives in which package; it points to the format matrix on the documentation site. If you cannot say which extensions your users upload, you cannot pick correctly.

Finally, the naming history is a real hazard. The README states that historical `@flyfish-group/*` package names remain compatibility aliases and that `doc.flyfish.dev` is a legacy documentation domain that should resolve to `doc.file-viewer.app`. Meanwhile the root package.json still carries the name `@flyfish-group/file-viewer-open-source` while the published packages use the `@file-viewer/*` scope. Anyone copying an install command from an older tutorial can end up on the alias. The README's advice is to verify a release through the repository, its public release page, and the published npm package metadata.

Alternatives: a conversion backend versus in-browser parsing

The realistic alternative for most teams is a server-side conversion pipeline. You upload or stream the file to a service, it converts to PDF or HTML or images, and the front end displays the result. That approach handles a wider range of malformed files, because the converter runs in a controlled environment where you can install native libraries and retry failures. It also gives you one output format to style.

The difference in approach is where the file goes and who pays for the CPU. File Viewer keeps the bytes in the browser and spends the client's CPU on parsing, which is why the README can say no mandatory conversion backend. The conversion approach spends server CPU and moves the file across a network boundary. For an internal app under a data-residency constraint, that boundary is the deciding factor. For a public app that must open whatever a stranger uploads, the server pipeline is usually the safer choice, because a malformed file becomes your problem in the browser rather than in a sandbox you control.

There is a middle ground worth naming: the README mentions the Full compatibility package as an option for an existing application, which suggests teams already running a preview stack can adopt the components incrementally rather than replacing everything at once.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-09. The release list shows v3.0.1, v3.0.2 and v3.0.3 all landing within the first ten days of September 2026, which is a fast patch cadence for a version line. The root package.json reports version 3.1.1, ahead of the newest published tag, so the workspace version and the release tag are not the same number. Treat the release page and the npm metadata as the source of truth, as the README itself instructs.

The licence is Apache-2.0. That permits commercial and internal use and includes a patent grant, which matters for a component that embeds third-party WASM renderers. It also means you carry the notice and attribution obligations that come with the licence. This is not legal advice; read the LICENSE file in the repository and the licence terms of the bundled renderers before shipping.

Upgrade cost is the part the README does not document. There is no rollback procedure described, and no migration guide for moving between major versions is referenced. What the repository does give you is a CHANGELOG.md, a RELEASE_TEMPLATE.md and a public CI workflow, so the release notes are the place to look. The `verify:public-release-facts` script that gates both the full build and the demo build is a notable choice: the project enforces its own published facts at build time, which is unusual and suggests version drift is something the maintainers actively guard against.

Editorial conclusion

Adopt File Viewer if your internal app already holds the file bytes and the constraint is that they must not leave your network; the CLI integration path and the framework-specific packages are the parts to evaluate first. Do not adopt it if you want a desktop viewer, a hosted preview API, or a single bundle that renders every format without per-format asset work. Before committing, check the format matrix for the exact extensions you need, confirm the renderer assets can be served from your own origin, and decide between the light and full packages, because that choice determines what ships to the first screen.

Frequently asked questions

Official sources

1. flyfish-dev/file-viewer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases