What is PJPEG?

PJPEG commonly refers to progressive JPEG, which stores an image in multiple scans. A decoder can show a coarse version of the entire image before later scans add finer detail.

How PJPEG works

A progressive JPEG divides coefficient information into a sequence of scans rather than coding each image region to completion in one pass. Early scans establish the broad structure across the frame, and later scans supply additional frequency detail or coefficient precision. It remains part of the conventional JPEG ecosystem, so it can pass through normal photographic asset pipelines, but the visible refinement behavior depends on both decoder and presentation software.

Key facts

  1. Progressive JPEG is a mode of the JPEG standard, not a separate format: the same quantized DCT coefficients are spread over several scans, divided by spectral selection (bands of coefficients), successive approximation (most significant bits first), or both. It is not a stack of independently encoded thumbnails. A parser can read the mode from the frame header marker: FF C2 (SOF2) for a Huffman-coded progressive file, FF C0 (SOF0) for baseline.
  2. Neither the file extension nor the media type identifies the mode. Progressive files normally keep .jpg or .jpeg and image/jpeg; MDN also lists .pjpeg and .pjp as JPEG extensions. image/pjpeg is not in the IANA registry. It is the label that Internet Explorer’s MIME detection returned for JPEG data in general, for backward compatibility, so an upload labeled image/pjpeg is not necessarily progressive, and an allowlist that handles such legacy clients has to treat it as JPEG and inspect the content.
  3. Decoding a progressive file and showing its intermediate passes are separate things. libjpeg-turbo returns only the final image unless the application uses its buffered-image mode, and its documentation says each displayed pass costs about as much work as decoding a full image. A multi-scan file also needs a full-image coefficient buffer, where a single-scan file needs only buffers proportional to the image width, and libjpeg-turbo’s tools offer a scan limit because crafted files with very many scans can consume excessive CPU. Budget memory and cap the scan count when decoding untrusted uploads.
  4. At the same quality setting, a progressive file decodes to the same final image as a sequential one and is about the same size, often slightly smaller, according to libjpeg-turbo’s documentation. Choose it for incremental display, not for savings. The standard does not require implementations to provide every mode, and some embedded decoders, such as TJpgDec, support baseline only.

When PJPEG matters

Choose progressive JPEG when early visual feedback during a large photographic download is valuable. Mainstream browsers and imaging libraries decode progressive scans reliably, so reserve compatibility checks for constrained targets such as embedded or hardware decoders that implement only baseline JPEG.

How Transloadit helps with PJPEG

Transloadit’s /image/resize Robot has a progressive parameter that interlaces the output so that browsers can show a low-resolution version of the whole image before the rest of the data arrives; it is off by default. The image formats table also lists PJPEG next to JPG and JPEG as a format name that its ImageMagick-based Robots can read and write.

The Robot documentation states a file-size cost for progressive and does not say which output formats the option or that cost applies to. libjpeg-turbo’s documentation describes progressive JPEG files as about the same size as sequential ones, often slightly smaller, so measure with your own images. The documentation does not describe what choosing PJPEG as the output format changes compared with JPG.

Explore Transloadit’s file formats & compression capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free