What is a zero-footprint DICOM viewer?

Ten years ago, reading a study from home meant a Windows laptop, a VPN client, a thick PACS client that someone from IT had installed, and sometimes a Java version that only worked with one browser. If the radiologist changed laptops, the whole thing started again. Many Indian centres still work this way for the reporting room, and use a mix of CDs, JPEG exports and WhatsApp photos for everyone else.

A zero footprint DICOM viewer removes most of that. The term gets used loosely, though, and two viewers that both claim it can behave very differently on a slow line or a shared PC. So, let's look at what the term actually means, how these viewers work under the hood, and what to check before you trust one with diagnostic reads.

What "zero footprint" means

A zero footprint viewer runs entirely inside a standard web browser. Nothing is installed on the computer: no client software, no plug-in, no Java or ActiveX, no admin rights needed. You open a link, log in, and the images appear.

The second half of the definition is often forgotten. "Zero footprint" should also mean nothing is left behind. When the session ends, no images, patient names or reports should be sitting in a downloads folder or a disk cache on that machine. A viewer that installs nothing but leaves a folder of DICOM files on a shared reporting PC has a footprint, just a hidden one.

Two ways to put pixels on the screen

Every web viewer has to decide where the image is actually drawn. There are two broad approaches, and the choice shapes how the viewer feels.

Client-side rendering. The browser downloads the pixel data from the archive, usually through DICOMweb (the web flavour of the DICOM network services, explained in our guide to what DICOM is), and draws it locally using the computer's graphics card through WebGL. A well-built viewer streams a volume progressively onto the GPU, so the radiologist starts working before every slice has arrived.

The advantage is that once the data is in the browser, everything is instant. Scrolling, window-level, zoom and MPR happen on your own GPU with no round trip to a server. It also keeps server costs low, because the server mostly serves files. The cost is bandwidth and local hardware: a large thin-slice CT has to come down the line, and a very old laptop with integrated graphics will struggle with big volumes.

Server-side rendering. The images stay on the server. The server renders each view and streams the result to the browser as compressed frames, a bit like a video call, and the browser is only a display. The DICOM standard has added web services for this kind of work; Supplement 228 defines services for volumetric rendering done on the server.

The advantage here is a very thin client. A phone can show a 3,000-slice study because it never receives the 3,000 slices: the original DICOM data stays on the server, and only the rendered frames you look at are sent. However, every interaction is a round trip. On a stable office line it feels fine. On a 4G connection in a moving car, or a broadband line shared with the whole house, each scroll waits for the server, and the frames you see may be compressed more heavily than the original.

Many viewers mix the two: stream a quick first view from the server, then pull full data to the client for heavy work. When you evaluate one, ask which approach it uses for which task, and try it on the worst connection your radiologists actually use, not the demo Wi-Fi.

What radiologists and referring doctors need

Ask a radiologist what makes a viewer good and the answers are rarely about features on a brochure. They are about minutes saved over a 200-study day. A viewer that is fit for diagnostic reading can be characterised as follows:

1. Time to first image. Click a study, and something useful should be on the screen in a second or two. If the viewer waits for the whole study to load before showing anything, that wait multiplies across the shift.
2. Priors, automatically. The previous CT of the same patient should be found and hung next to today's study without anyone searching for it. This depends on the archive and on patient ID matching as much as on the viewer.
3. Hanging protocols. A chest CT, a brain MR and a four-view mammogram should each open in the layout that radiologist prefers, with the right series in the right place.
4. MPR and MIP. Multiplanar reconstruction and maximum intensity projection in the browser, without exporting to a separate workstation for routine cases.
5. Measurements that hold up. Length, angle, ROI with mean HU, and measurements that are saved with the study so the next reader sees them.
6. Keyboard and mouse behaviour that does not fight you. Scroll, window-level presets, next study, all reachable without hunting through menus.

If a viewer is fast on a single CR but slow to open a 1,200-slice CT with a prior next to it, it is not ready for diagnostic work. Increasingly there is a seventh requirement: the viewer has to display AI results stored as standard DICOM objects, rather than a separate vendor window. Herman Oosterwijk's article on using the IHE AI Results profile sets out what that involves, and our own AI results checklist turns it into questions for a viewer vendor.

The same viewer often serves a second, very different user. A radiologist reporting a study needs the full-fidelity image, a proper calibrated display and the complete toolset. Professional bodies set out what diagnostic display should look like; the ACR–AAPM–SIIM technical standard for electronic practice of medical imaging (revised 2022) covers display characteristics such as luminance response and pixel pitch. A browser viewer does not change those requirements, and the monitor still matters. A referring orthopaedic surgeon or physician usually wants something else: the report, the key images the radiologist marked, and the ability to scroll through the study on a phone between patients. For them, simplicity matters more than MPR. A good setup gives them a link that opens straight to the right study, shows key images first, and does not ask them to create an account they will forget.

For a lot of referring doctors in India, the phone is where they look at images, whether we like it or not. A zero footprint viewer is the cleanest answer to that, because the alternative in many centres is a photo of the monitor sent over WhatsApp. For radiologists, a phone is useful for a quick look at an urgent study or a second opinion at night. Most will tell you they would not sign a complex report off a phone screen, and they are right to be careful.

Security: keeping patient data off the device

A browser viewer is only as safe as the way it is deployed. A few things to check:

1. Nothing written to disk. With client-side rendering, pixel data has to be in the browser's memory while you work. It should be held there, not saved to the downloads folder or a persistent cache, and cleared when the tab closes.

2. Links that expire. Study links sent to referring doctors should be time-limited and tied to that study, not a permanent public URL.

3. Session timeouts and logout on shared reporting PCs, so the next person does not inherit the previous login.

4. Encrypted transport (HTTPS) end to end.

5. Audit logs of who opened what, and when. India's DPDP Rules, 2025 list access control and logging among the reasonable security safeguards a data fiduciary will be expected to have (Rule 6, which applies from around May 2027).

How we built ours

The practical upshot for a centre choosing a viewer is simple to state and takes an afternoon to test. Decide which users need full diagnostic tools and which need a link and key images, try the viewer on your slowest real connection with a large CT and its prior, and check what is left on the machine after the session ends.

Related reading

• DICOM explained — DICOMweb, worklists and why "it's DICOM" is not enough.

FAQ

What is a zero footprint DICOM viewer?

It is a medical image viewer that runs entirely in a standard web browser, with no software, plug-in or admin rights needed on the computer. Whether it leaves patient images or data on the device after the session depends on its caching settings, so check that separately.

Is client-side or server-side rendering better?

Neither is better everywhere. Client-side rendering feels instant once data has loaded and keeps server costs down, but needs bandwidth and a reasonable GPU. Server-side rendering works on very thin devices and keeps pixel data on the server, but every interaction depends on network latency. Test both on your radiologists' real connections.

Can radiologists report diagnostically from a browser viewer?

Yes, if the viewer delivers full-fidelity images and the tools they need, and the reading station has a suitable display. The browser does not replace the need for an appropriate diagnostic monitor.

Is it safe to send study links to referring doctors on WhatsApp?

A time-limited, access-controlled link to a secure viewer is far safer than sending images or photos of the screen, because the images are not attached to the chat and access can expire (the message itself stays). Check that links expire and that access is logged.