DICOM transfer syntax: every UID, and which viewers decode them

What a transfer syntax is

A DICOM transfer syntax is the encoding rule set that defines how the data elements and pixel data of a DICOM object are serialized into bytes, whether for a file on disk or a stream on the wire. A DICOM object is a structured set of elements, each identified by a tag, and the transfer syntax fixes exactly how that structure and its pixels are laid out so that any conformant reader can decode them without guessing.

Three separate choices are bundled into every transfer syntax. The first is byte ordering, little endian or big endian, which decides the order in which the bytes of a multi-byte value are written. The second is whether the value representation of each element is explicit or implicit. The third is how the pixel data is encoded: native, meaning uncompressed, or one of several compressed schemes. The combination is named once, by a single UID, and that UID travels with the object so the reader knows all three answers at once.

Byte order and value representation

The value representation, or VR, is the data type of an element: a person name is PN, an unsigned short is US, a date is DA, and so on. In an explicit VR transfer syntax the two-letter VR code is written into the stream next to each element, so the reader learns the type directly from the bytes. In an implicit VR transfer syntax the code is omitted and the reader has to look the tag up in a data dictionary to recover the type. Explicit is more self-describing; implicit is more compact but leans on the reader knowing the dictionary.

Byte order rides alongside that choice. Little endian stores the least significant byte first and is by far the most common in modern practice; big endian stores the most significant byte first and survives mainly as a retired option in older data. Almost all contemporary DICOM is little endian, and the two transfer syntaxes you see most often are the two that combine little endian with an implicit or explicit VR.

Native versus compressed pixel data

The part of a transfer syntax that has the largest practical effect is how it encodes the pixel data. In a native transfer syntax the pixels are stored uncompressed, exactly as acquired. In an encapsulated transfer syntax the pixel data is wrapped in a compressed bitstream, and the transfer syntax UID names the precise codec: JPEG Baseline, JPEG Lossless, JPEG-LS, JPEG 2000, or run length encoding (RLE), among others.

Whether that compression is lossy matters clinically, and the transfer syntax is where the answer is stated. Some encodings discard information to save space and some do not:

• Lossless. JPEG Lossless, JPEG-LS in its lossless mode, most RLE, and the reversible profiles of JPEG 2000 reconstruct the original pixels bit for bit.
• Lossy. JPEG Baseline and the irreversible profiles of JPEG 2000 trade some pixel fidelity for a smaller file, which is acceptable for some uses and not for others.
• Native. No compression at all, largest on disk, nothing discarded, and the simplest for any reader to decode.

Because the codec is named in the transfer syntax rather than hidden in the pixels, a receiving system knows before it decodes whether it can handle the encoding and whether the image has already been through lossy compression.

Every DICOM transfer syntax UID (PS3.6 2026c)

The complete registry from DICOM PS3.6 Annex A, table A-1: 63 transfer syntaxes, 18 of them retired. Name and UID are verbatim from NEMA; the codec, byte order and notes columns are our annotation. Download it as CSV.

Which free DICOM viewers decode which transfer syntax

A UID table tells you what a transfer syntax is. It does not tell you whether the viewer on your desk can open it. So we tested: the same nine files, one per common transfer syntax, opened in 12 free viewers on 2026-08-28. Every cell is an observed result with a screenshot behind it; nothing comes from vendor brochures. Download the matrix as CSV.

What the matrix shows

• Deflated Explicit VR Little Endian is the universal weak spot. Seven of the eight web viewers fail it, and so does Horos: the OHIF-based ones show a blank viewport and log "no COMPRESSED_FRAME_DATA for imageId", CT Read says "Failed to load DICOM file", the rest reject the file silently. It is rare in the wild, but some archives emit it.
• Horos 4.0.1 renders RLE Lossless with corrupt pixels (a near-white, speckled image) and shows a flat grey placeholder for the deflated file. The same RLE file decodes correctly in DCMTK, Weasis and every OHIF-based viewer, so the file is valid and the decoder is not.
• JPEG Baseline trips two viewers: IMAIOS spins on "Loading" without ever drawing, and TrazaLab never loads the study, consistent with its own stated support list (uncompressed, RLE and JPEG lossless only). Big endian, JPEG 2000 and JPEG-LS also fail there.
• Three viewers passed all nine: Weasis 4.7.3, the MiniPACS in-browser viewer, and X-ray Interpreter (judged from its decoded thumbnails only, see caveats).

Method and caveats

Same nine fixture files opened in every viewer. PASS = pixel image visibly rendered in a screenshot reviewed by a person; FAIL = blank viewport, corrupt pixels or an error; UNTESTED = the viewer could not be driven to load that file. Browser viewers were driven with Playwright Chromium and given 20 seconds per file; desktop viewers ran on macOS and were screen-captured. Nothing is inferred from vendor documentation.

• onlinedicom.com: Three cells untested: the app intermittently failed to hydrate behind a bot check.
• X-ray Interpreter: PASS judged from the decoded series thumbnail only; the full viewport could not be opened under automation.
• The fixtures are built from two public, de-identified teaching studies (the BRAINIX MR brain and the INCISIX dental CT, no patient data) transcoded with DCMTK 3.7, plus a JPEG 2000 pair from the pydicom test set. SHA-256 of every file is in the CSV, and the full set is downloadable below, so anyone can reproduce a cell.
• MicroDicom and RadiAnt are Windows-only and were not run. Their documentation lists uncompressed, RLE, JPEG lossy and lossless, and JPEG 2000 (RadiAnt also JPEG-LS); neither mentions deflated or big endian. Documented is not tested, so they are not in the table.
• Nine syntaxes cover what clinical modalities actually emit today. HTJ2K, JPEG XL and the video syntaxes were not tested; we will add them when we have valid fixtures.

Download the fixture set

Every file behind the matrix is downloadable as one archive, so you can run the same test against your own viewer or PACS: minipacs-transfer-syntax-fixtures.zip (about 2 MB, no patient data). It contains 13 DICOM files: the nine matrix syntaxes plus two bonus lossy encodings the matrix does not cover yet (JPEG Extended Process 2 and 4, and JPEG-LS near-lossless), and the uncompressed twins of the RLE and JPEG 2000 files.

• Objective pass criterion: the six lossless MR encodings (Implicit, Explicit, Big Endian, Deflated, JPEG Lossless, JPEG-LS) decode to byte-identical pixels: PixelData MD5 e092a3ac4664bfb94e99c254f9c3385e after conversion to Explicit VR Little Endian with DCMTK 3.7. The RLE and JPEG 2000 files must match their included uncompressed twins. If a decoder produces anything else on a lossless syntax, it is wrong, not different.
• manifest.csv lists every file with its transfer syntax UID, MD5, SHA-256, expected decoded-pixel hash and provenance; README.txt documents how each file was produced and how to verify a decoder. Two reference PNG renders show what a correct decode of the MR and CT source looks like.
• Sources: the BRAINIX and INCISIX teaching studies plus the pydicom-data JPEG 2000 pair. Compressed variants were produced with DCMTK 3.7.0, and every file's TransferSyntaxUID was re-verified with dcmdump before packaging.

Cite or reuse: the tables and the fixture compilation are CC BY 4.0, link to this page and name the test date. Found a cell that is wrong on a newer viewer version? Write to contact with the version and a screenshot and we will re-run it.

Why systems must negotiate one

A transfer syntax is only useful if both ends of an exchange share it. When two DICOM nodes open a network association over the DICOM protocol, they negotiate presentation contexts. For each type of object the sender wants to transmit, it proposes a set of transfer syntaxes it is willing to use, and the receiver accepts one it can decode. This is presentation context negotiation, and it is the reason a DICOM connection works even between systems built years apart by different vendors.

If the two nodes share no transfer syntax for a given object, that presentation context is rejected and the study cannot cross that association as-is. The fix is transcoding: one side re-encodes the object into a transfer syntax the other understands, for instance decompressing a JPEG 2000 study into Explicit VR Little Endian so a reader without the codec can open it. Because Implicit VR Little Endian is the mandated baseline, a conformant node can always fall back to it, which is what keeps the network from deadlocking. For how that negotiation sits inside DICOM networking, see the DICOM server overview.

Where this matters in practice

The transfer syntax is not an abstraction; it decides whether a study opens, how much it costs to store, and whether an image has been through lossy compression. A modern archive stores whatever syntax a modality sends and negotiates a common one on the way out, so the clinician never sees the plumbing. A standards-based archive and server like MiniPACS handles the standard transfer syntaxes clinical modalities produce; the exact accepted and transcoded set for a deployment belongs in its DICOM conformance statement rather than a blanket claim, so a hard requirement is worth confirming there.

For the bigger picture of how archives and viewers fit together, see what is PACS and how a DICOM viewer opens the studies once they have arrived. The transfer syntax is the layer underneath all of it: the rule that turns a study into bytes and back again.

FAQ