react-file-viewer is a React component for previewing documents and images in the browser, and while it has no known direct vulnerabilities, it has gone years without a release, so treat it as a dormant dependency you adopt with eyes open. The react-file-viewer package renders PDFs, images, spreadsheets, and a handful of other formats inside a React app without wiring up a separate viewer per type. That convenience is real, but so is the maintenance risk, and this guide walks through both.
What react-file-viewer does
The react-file-viewer npm package exposes a single component you point at a file and a file type. It handles rendering for common formats such as PDF, PNG, JPEG, CSV, DOCX, and a few others, choosing the right internal renderer based on the type you pass:
import FileViewer from 'react-file-viewer';
function Preview({ url, type }) {
return (
<FileViewer
fileType={type}
filePath={url}
onError={(e) => console.error('viewer error', e)}
/>
);
}
It is genuinely handy for internal tools and dashboards where you need a quick preview without building a rendering pipeline. The download numbers reflect that: it still pulls on the order of twenty thousand downloads a week.
The maintenance reality
Here is the part that should shape your decision. The latest published version of react-file-viewer is 1.2.1, and it was last published around seven years ago. Its maintenance status is classified as inactive, and it has seen no new npm releases in well over a year. On the positive side, advisory databases including Snyk report no known direct vulnerabilities in the package itself.
So the risk is not a specific CVE. It is structural. A component that renders untrusted file content is exactly the kind of code you want receiving security updates, and this one is not receiving them. It also pins older versions of its own rendering dependencies, and those transitive packages are where problems tend to accumulate over a seven-year gap. The honest summary: no known holes today, but no one is watching the door.
Why a file viewer deserves extra scrutiny
Rendering a file the user supplied is an attack surface, not a neutral operation. A PDF can carry embedded JavaScript. A spreadsheet can carry formula-injection payloads. An SVG is XML that can carry script. When a viewer parses these formats in the browser, any parsing bug or unsafe rendering path becomes a potential cross-site scripting or content-spoofing vector. That is fine when the library is patched promptly, and it is a slow-building liability when it is not.
If you use react-file-viewer with files that untrusted users upload, put controls around it regardless of the library's state. Serve user-uploaded files from a separate, cookieless origin so a rendering exploit cannot reach your app's cookies or session. Enforce a Content Security Policy that blocks inline script. Validate the real file type on the server rather than trusting the extension or the client-declared type. And check react-file-viewer in your dependency tree with a scanner so you learn immediately if an advisory ever lands. An SCA tool such as Safeguard flags dormant, unmaintained packages precisely because "no CVE yet" and "safe" are not the same thing.
react-file-viewer versus react-native-file-viewer
The names collide but the packages solve different problems. react-file-viewer is a web component that renders file contents inline in a browser DOM. react-native-file-viewer, by contrast, is a React Native module that hands a file off to the mobile operating system's native viewer, opening a PDF in the OS document viewer rather than drawing it inside your app. If you are building for mobile, react-native-file-viewer is the relevant package and it delegates rendering to the platform, which sidesteps the in-app parsing surface entirely. Do not assume anything about one from the other; they share a naming convention and nothing else.
Safer alternatives for web previews
If you are starting fresh or willing to migrate, a few directions age better than a dormant all-in-one viewer. For PDFs specifically, Mozilla's actively maintained PDF.js (often via a React wrapper) is the standard and gets regular security updates. For images, the browser already renders them natively; you rarely need a library at all. For office documents, consider rendering server-side to a safe format like PDF or HTML in a sandboxed worker, so the untrusted parsing never happens in your users' browsers.
The general principle: prefer narrow, maintained, single-purpose libraries over a broad convenience wrapper that has stopped receiving updates. A viewer that does one format well and ships patches is worth more than one that does six formats and has not changed since before the current React version existed. Our SCA product overview covers how to spot these dormant convenience packages across a codebase, and the Safeguard Academy has guidance on evaluating open-source dependencies before you adopt them.
If you decide to keep it
Sometimes the pragmatic call is to keep react-file-viewer because it works and rewriting the preview feature is not worth it this quarter. That can be defensible if you constrain it. Pin the exact version so nothing shifts under you. Only feed it files from trusted sources, or isolate untrusted files on a separate origin. Wrap it so a render failure degrades to a download link rather than a broken page. And set a calendar reminder to reassess, because "we will replace it later" has a way of becoming permanent.
FAQ
Is react-file-viewer safe to use?
It has no known direct vulnerabilities, but it is an inactive package whose last release was years ago. That makes it acceptable for trusted, internal content with proper isolation, but risky for rendering files from untrusted users without additional controls.
When was react-file-viewer last updated?
Its latest version, 1.2.1, was published roughly seven years ago, and the project is classified as inactive with no recent npm releases.
Is react-file-viewer the same as react-native-file-viewer?
No. react-file-viewer renders file contents inline in a web browser, while react-native-file-viewer is a mobile module that opens files in the operating system's native viewer. They share a naming pattern but solve different problems.
What should I use instead for PDFs?
Mozilla's PDF.js is the actively maintained standard for browser PDF rendering and receives regular security updates, which makes it a stronger choice than a dormant multi-format viewer for the PDF use case.