OHIF Viewer: a zero-footprint DICOM viewer you configure instead of fork

What OHIF Viewer solves, and for whom

The README describes OHIF Viewer as a zero-footprint medical image viewer provided by the Open Health Imaging Foundation, with out-of-the-box support for image archives that speak DICOMweb. Zero-footprint means the image handling happens in the browser rather than in an installed desktop client. For a radiology department, a research group, or a vendor building on top of an existing PACS, that removes an install step for every workstation.

The audience is narrower than a general imaging tool. The repository topics list cancer-imaging-research, nci-itcr, nci-qin and quantitative-imaging alongside the generic dicom and reactjs tags, and the description names an oncology specific Lesion Tracker. The README's feature gallery covers measurement tracking, labelmap segmentations, fusion and custom hanging protocols, RT STRUCT, 4D, slide microscopy, ECG waveform, PDF and structured report rendering. Those are the features a clinical trial or a tumor board cares about, not a photo viewer's checklist.

The practical entry condition is DICOMweb. If your archive exposes QIDO-RS, WADO-RS and STOW-RS, the viewer can retrieve and load from it. If your images live only in a proprietary protocol or on a shared filesystem, the README does not describe a path for you.

How the extension system replaces forking

The README states that all of the viewer's core features are built using its own extension system, and that the same extensibility lets you customize the viewer for your workflow and add functionality you maintain privately without forking. That is the central architectural claim, and it shapes how upgrades work: a private extension can sit alongside the published core rather than inside a modified copy of it.

The repository layout backs this up. There are top-level extensions/, modes/ and platform/ directories, a pnpm-workspace.yaml, and a root package.json whose name is ohif-monorepo-root and which is marked private. Platform scripts build the application through a filter, for example pnpm --filter @ohif/app run build:viewer, and there are dedicated build targets for ci, qa and demo. Modes are a separate concept from extensions: the demo links in the README point at distinct routes such as /viewer, /tmtv, /microscopy and /dynamic-volume, which suggests a mode bundles the layout and behaviour for a clinical task while extensions supply the underlying capability.

The trade-off is that you are adopting a plugin architecture, not a single application. Configuration and extension code are where your effort goes, and the README does not pretend otherwise: it says almost everything offers some degree of customization and configuration.

Installing OHIF Viewer and running it locally

The root package.json pins the toolchain: packageManager is [email protected], and engines require node >=24 and pnpm >=11. There is a preinstall script, node preinstall.js, which the Dockerfile comments explain must be present before install runs or the install fails with MODULE_NOT_FOUND. Install dependencies from the repository root:

pnpm install

The README and package.json together point at docs.ohif.org for build and configuration detail, so treat that site as the authority for anything beyond dependency installation. To start the development viewer, the root package.json defines a dev script that delegates to the app package:

pnpm run dev

For a production build, the root script filters the app package and runs the viewer build:

pnpm run build

The repository also ships a Dockerfile that publishes the ohif/app image. Its comments describe two stages: building the React application for production, then packaging the output into an Nginx Alpine image that serves it as static content. The build context must be the project's root directory, and the file gives the build command in a comment:

docker build -t ohif/viewer:latest .

For a first real use, the fastest check is the hosted demo at viewer.ohif.org, which the README links with example StudyInstanceUIDs query parameters. To point a local instance at your own archive you need to configure the DICOMweb endpoint; the package.json has a show:config script that echoes APP_CONFIG and PUBLIC_URL, which tells you those are the variables a deployment sets, but the README does not spell out the endpoint configuration itself. Read docs.ohif.org for that step.

Where OHIF Viewer is the wrong choice

The first failure mode is a missing DICOMweb server. The README's support statement is explicit that the viewer has out-of-the-box support for archives which support DICOMweb. Nothing in the README describes a DICOM C-FIND/C-MOVE client or a local file loader for arbitrary DICOM directories, so if your only route to the images is a legacy protocol, you are outside the documented path.

The second is deployment complexity. This is a pnpm monorepo requiring Node 24 and pnpm 11, with a preinstall script that has already caused a documented failure when the build context was incomplete. The Dockerfile comments note that .dockerignore excludes platform/docs, so the lockfile's docs importer has no manifest in the build context and a frozen install would fail there; the file keeps --no-frozen-lockfile for that reason. That is a build system with sharp edges, and a team without JavaScript build experience will feel them.

The third is the gap between the repository and a regulated product. The README says the viewer has served as the basis for many FDA Cleared medical imaging viewers, but it does not claim that this repository is itself cleared, and it directs commercial and academic enquiries to a separate Get Support page. If you need a signed device, you are building one on top of a library, not downloading one.

Finally, if you only need to look at a handful of studies once, the hosted demo already does that. Standing up the monorepo is not justified by occasional viewing.

OHIF Viewer compared with Cornerstone.js alone

The natural alternative is to build directly on Cornerstone.js, the rendering library. The OHIF README links to a Cornerstone Slack channel for community questions, which reflects how closely the two projects sit together.

The difference in approach is scope. Cornerstone gives you the image rendering primitives and leaves the application to you: study list, viewer layout, toolbar, side panels, hanging protocols, measurement serialization, user access control, internationalization and OpenID Connect are all things OHIF ships and Cornerstone does not. Choosing Cornerstone means writing those yourself and owning them forever.

Choosing OHIF means accepting its extension and mode model as the place where your differences live. The README frames this as the reason the viewer was rebuilt from the ground up after more than eight years of integrations, to address varying workflow and configuration needs. If your requirements are close to the built-in modes, that is a large amount of application code you do not write. If your requirements are far from them, you may spend as long bending the extension points as you would have spent building on the primitives.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-22. The most recent releases listed are v3.12.18 on 2026-09-21, v3.12.17 on 2026-09-10 and v3.12.15 on 2026-09-08. That is a patch-level cadence on the 3.12 line, which matters for upgrade planning: you should expect to move between patch releases rather than wait for a major version.

The cost of upgrading is set by how much you changed. Because the README's stated design goal is that private functionality can be maintained without forking, an installation that keeps its differences inside extensions and modes should track upstream releases with relatively little work. An installation that patched core files directly inherits the fork problem the extension system was built to avoid.

The licence is MIT. The README displays an MIT License badge and the repository contains a LICENSE file. MIT is permissive: it allows commercial use and modification, and it does not require you to publish your changes. It also provides no warranty and no patent grant, and it does not by itself make a medical device compliant with any regulator. Whether your use needs additional clearance, a quality management system or a support contract is a question for your own regulatory and legal advisors, not something the licence text settles.

Support channels listed in the README are GitHub issues for bugs and feature requests, a community forum, a Slack channel, and a separate commercial support page.

Editorial conclusion

Adopt OHIF Viewer if you already run a DICOMweb archive and need a browser-based viewer you can extend without forking, and if your team can work inside a pnpm monorepo on Node 24. Do not adopt it if you have no DICOMweb endpoint, or if you need a vendor to hold your hand through a clinical deployment; commercial support exists but is a separate arrangement. Before committing, verify three things: that your archive answers DICOMweb queries at the URL you intend to configure, which APP_CONFIG your deployment will use, and whether the extensions you need already exist or must be written. The repository's own Dockerfile is the shortest path to a running instance, so start there and read docs.ohif.org before writing any extension code.

Frequently asked questions

Official sources

1. License: MIT
2. OHIF/Viewers on GitHub
3. Project website
4. README
5. Releases