viewhack

DICOM viewer: the scans from a hospital CD, on your own computer

Drop the whole folder from the CD or USB stick the hospital gave you, or a few files from it. The CT, MRI, X-ray or ultrasound images are sorted into their series, and you can scroll through the slices, change brightness and contrast, and read every tag in the file header. No Windows viewer program needed.

Your scans are read by this tab on your own device. Nothing is uploaded, and closing the tab forgets them.

Picks every file under the folder, like dropping it. Many phones cannot pick a folder; choose several files there instead.

Ask the doctor who ordered the scan what it shows.

What you get

Why a CD needs a whole-folder viewer

A hospital CD is usually laid out like this: a DICOMDIR index file, a folder such as DICOM/ or IMAGES/ with hundreds of files named like IM000001 or I1000000 (often in sub-folders per study and series), and a viewer program for Windows with an autorun.inf that starts it. On a Mac, a Chromebook, Linux, or a Windows PC that blocks autorun, that viewer does not start. A CT is one file per slice: 512 × 512 pixels at 16 bits is 512 KB, so a 300-slice scan is about 150 MB spread over 300 files, and a disc often holds several series (with and without contrast, thin and thick slices, the scout image).

Here every file you drop is looked at: DICOM files are recognised by the letters DICM after their 128-byte preamble (or, for older discs, by a bare data set starting at group 0008), and everything else is counted and skipped. Only each file's header, the first 512 KB at most, is read to build the list; a slice's pixels are read when you look at it.

What it can decode

Uncompressed
Implicit VR little endian, explicit VR little endian and explicit VR big endian. 8-, 16- and 32-bit pixels, signed or unsigned, with RescaleSlope and RescaleIntercept applied (for CT this gives Hounsfield units: air is about −1000, water 0). MONOCHROME2, and MONOCHROME1, where high values are dark, shown the right way round. RGB, both interleaved and planar (PlanarConfiguration 0 and 1), and YBR_FULL.
JPEG Baseline (1.2.840.10008.1.2.4.50)
The compressed fragment is handed to your browser's own JPEG decoder. Common on ultrasound, endoscopy and secondary-capture images.
RLE Lossless (1.2.840.10008.1.2.5)
Decoded by viewhack's own code.
JPEG Lossless (1.2.840.10008.1.2.4.57 and .70)
The lossless JPEG of 1993 (process 14), common on older CT and MR discs. Your browser's own JPEG decoder cannot read it, so a 15 KB open-source decoder (jpeg-lossless-decoder-js) does.
JPEG-LS (.80 lossless, .81 near-lossless)
Decoded by CharLS compiled to WebAssembly (about 200 KB). Near-lossless files are shown as stored: each pixel may differ from the original scan by at most the NEAR value written in the file (2 means ±2 units).
JPEG 2000 (.90, .91) and HTJ2K (.201, .202, .203)
Decoded by OpenJPEG compiled to WebAssembly (about 320 KB), which also reads the newer High-Throughput JPEG 2000. The lossy variants (.91, .203) are shown as the scanner stored them; the discarded detail cannot be brought back.
Deflated (1.2.840.10008.1.2.1.99)
Everything after the file's short opening group (the rest of the header and the image) packed with deflate, the method ZIP files use. Your browser unpacks it with its own built-in DecompressionStream.
Loaded only when needed
A decoder is fetched from viewhack itself the first time you open a series that needs it, so an uncompressed CD downloads none of them. It runs in this tab like the rest of the page: your scan is still not uploaded anywhere.
Not yet
JPEG Extended 12-bit (.51), JPEG 2000 Part 2 multi-component (.92, .93), JPIP-referenced files (.94, the pixels live on a hospital server) and video: MPEG-2, H.264 and HEVC (.100–.108). A series in one of these says so by name, for example This series is compressed with JPEG Extended (Process 2 and 4), which viewhack cannot decode yet, and its header is still shown.

Sharing one image safely

The header of a scan normally carries the patient's full name, date of birth and hospital ID number. Before you post an image on a forum or send it to someone who is not your doctor, you have two choices:

A PNG of the slice
Pixels only: no header, no tags. Nobody can scroll it, change its window, or measure it, so it is a picture, not a scan.
A de-identified copy of the DICOM file
The same file with these values overwritten by spaces, byte for byte in place, so the file keeps its exact length and structure and every DICOM viewer still opens it: PatientName (0010,0010), PatientID (0010,0020), PatientBirthDate (0010,0030), OtherPatientIDs (0010,1000), OtherPatientNames (0010,1001), PatientAddress (0010,1040), PatientTelephoneNumbers (0010,2154), ReferringPhysicianName (0008,0090), InstitutionName (0008,0080), InstitutionAddress (0008,0081) and AccessionNumber (0008,0050). Also blanked: patient birth time, birth name, mother's birth name, issuer of patient ID and patient comments; the referring physician's address and phone, physicians of record, performing and reading physicians and operators; station name, department and device serial number; study ID, admission ID and the requested and performed procedure IDs. The same tags are blanked inside sequences. A compressed file keeps its compressed pixel data byte for byte; only header values change. A deflated file is the one exception to "same length": its copy is saved inflated, as Explicit VR Little Endian, which every DICOM viewer reads.
What is not cleaned
Text burned into the pixels is not touched: some ultrasound images, X-rays, scanned documents and screenshots print the name, date of birth or hospital on the picture itself, and a PNG or de-identified copy keeps it. Vendor private tags (odd-numbered groups) are kept as they are, and some scanners store names in them. The scan dates, times, age, sex, UIDs and descriptions are kept too. Look at the picture and search the header table before you share.

What it cannot do