How does a browser display a DICOM file?

Displaying a medical image takes much more than an <img> tag.

https://apps.microsoft.com/detail/9nblggh514ph?hl=fr-FR&gl=FR

When we build web applications, displaying an image is one of the easiest things we do.

<img src="photo.jpg" />

The browser takes care of the rest.

It downloads the image.

Decodes it.

Displays it.

Simple.

Then you discover medical imaging.

Someone gives you a DICOM file and asks:

“Can we display this in the browser?”

At first, it sounds like another image.

It isn’t.

the browser doesn’t understand DICOM

Modern browsers know how to display formats like:

• JPEG
• PNG
• WebP
• SVG

DICOM isn’t one of them.

If you try to open a DICOM file directly in your browser, nothing useful happens.

That’s because a DICOM file isn’t just an image format.

It’s a medical data format.

Inside a single file, you might find:

• image pixels
• patient information
• acquisition settings
• scanner details
• image orientation
• study metadata

The browser has no idea what any of this means.

the image has to be decoded first

Before anything appears on the screen, the application needs to read the DICOM file.

Conceptually, the process looks something like this:

DICOM file
      |
Read metadata
      |
Extract pixel data
      |
Decode pixels
      |
Prepare image
      |
Display in browser

Only after those steps can the browser begin to render something meaningful.

pixels aren’t always ready to display

Another surprise for many developers is that the pixel values inside a CT scan aren’t always the values you finally see.

Medical images often require additional processing.

For example, CT images use numerical values representing tissue density.

Those values need to be transformed into something visible on a screen.

That’s why changing the window level can completely change what the doctor sees without changing the underlying image.

The application isn’t replacing the image.

It’s changing how those pixels are displayed.

rendering becomes a frontend problem

Now imagine doing this hundreds of times.

A CT study might contain several hundred slices.

The application needs to decode them, manage memory, and display them smoothly while the doctor scrolls through the study.

This isn’t something the browser provides out of the box.

Specialized rendering libraries handle much of this work.

They help transform medical data into something interactive.

where React fits

React doesn’t decode DICOM files.

Instead, it manages the application around the viewer.

Things like:

• layouts
• toolbars
• patient information
• navigation
• workflows
• user interactions

The rendering engine focuses on the image.

React focuses on the experience.

Together, they create the application the doctor sees.

the browser is doing much more than displaying an image

By the time the first CT slice appears, several things have already happened.

The application has:

• identified the study
• retrieved medical data
• decoded the DICOM file
• prepared pixel values
• rendered the image
• synchronized the interface

To the user, it feels instant.

Behind the scenes, there’s a lot happening.

this is why healthcare frontend development is different

Building healthcare applications isn’t just about creating beautiful components.

It’s about understanding data, performance, rendering, and clinical workflows.

The frontend becomes much more than a visual layer.

It becomes part of the medical imaging system.

And that’s what makes this field so interesting.

final thoughts

The next time you see a CT scan displayed in a browser, remember that the browser didn’t simply “open an image.”

It decoded medical data.

Processed pixel values.

Rendered the image.

Connected with healthcare systems.

And presented everything in a way that helps a clinician make decisions.

That’s a very different challenge from displaying a profile picture or a product photo.

And it’s one of the reasons healthcare web development continues to fascinate me.