Progressive JPEG vs Baseline:
Which Is Better for Web?

The Visual Loading Difference

The most obvious difference between progressive and baseline JPEG is how the image appears while it is still being downloaded by the browser. This matters because images are often the largest assets on a web page, and on slower connections they can take seconds to fully load.

Baseline JPEG: Top-to-Bottom

A baseline JPEG stores image data in a single scan, pixel row by pixel row, from the top of the image to the bottom. As the browser receives bytes, it renders what it has:

• At 10% loaded: The top 10% of the image is visible in full detail. The rest is blank or a placeholder.
• At 50% loaded: The top half is fully rendered. The bottom half is still missing.
• At 90% loaded: Almost complete, but the bottom edge is still blank.
• At 100% loaded: The full image is visible.

The user sees a “curtain reveal” effect — a sharp line between the rendered portion and the unloaded portion.

Progressive JPEG: Blurry-to-Sharp

A progressive JPEG stores image data in multiple scans (typically 3–5). The first scan contains the lowest-frequency DCT coefficients — the broad color and brightness information. Each subsequent scan adds higher-frequency detail.

• At 10% loaded: The entire image is visible as a very blurry, low-resolution preview. You can identify the subject, colors, and composition.
• At 50% loaded: The image is recognizable with moderate detail. Fine textures are still soft, but the overall impression is clear.
• At 90% loaded: Nearly full detail. Only the finest textures and edges are still slightly soft.
• At 100% loaded: Identical to the baseline version — full quality, every detail present.

The user sees the complete composition immediately, then watches it sharpen. This is psychologically more satisfying than watching a half-rendered image slowly grow downward.

How Progressive Scans Work Technically

To understand why progressive JPEG can be both perceptually better and slightly smaller, you need to know what those multiple scans actually contain.

Every JPEG image is broken into 8×8 pixel blocks, and each block is transformed into 64 DCT (Discrete Cosine Transform) coefficients. These coefficients range from the DC coefficient (the average brightness of the block — the lowest frequency) to the AC63 coefficient (the finest diagonal detail — the highest frequency).

In a baseline JPEG, all 64 coefficients for each block are written in a single pass. The encoder processes block after block, row by row, from the top of the image to the bottom.

In a progressive JPEG, the encoder makes multiple passes over the entire image:

1. Scan 1 (DC only): Writes just the DC coefficient of every block. This is enough to reconstruct an 8x-downsampled version of the image — the blurry preview.
2. Scan 2: Adds a few low-frequency AC coefficients (AC1–AC5). The image sharpens noticeably, edges appear.
3. Scan 3–4: Adds mid-frequency coefficients. Most detail is now visible.
4. Final scan: Adds the highest-frequency coefficients. The image reaches full quality.

The final result is mathematically identical to the baseline version. The same DCT coefficients, the same quantization, the same pixels. Only the byte order in the file differs.

File Size Impact

One of the less-known advantages of progressive JPEG is that it typically produces slightly smaller files than baseline at the same quality setting.

Why is progressive smaller? In progressive mode, similar DCT coefficients from across the entire image are grouped together in the same scan. This creates longer runs of similar values, which Huffman coding compresses more efficiently. In baseline mode, all 64 coefficients for one block are written together before moving to the next block — mixing low-frequency and high-frequency data that have very different statistical distributions.

The only exception is very small images under 10 KB — tiny thumbnails, icons, and avatars. For these, the overhead of multiple scan headers (each scan adds a few bytes of metadata) outweighs the compression benefit. But these images are so small that the difference is a few hundred bytes at most.

Perceived Performance and Core Web Vitals

From a pure technical standpoint, both progressive and baseline JPEG reach full quality at exactly the same time — when the last byte arrives. The total download time is identical (or slightly faster for progressive, given the smaller file size).

But web performance is not just about absolute speed. Perceived performance — how fast the page feels to the user — matters just as much. And this is where progressive JPEG has a clear advantage.

Users perceive progressive as faster

Research on perceived loading speed consistently shows that users rate progressive-loading images as loading faster than top-to-bottom baseline images, even when the actual download time is identical. The reason is straightforward: seeing the entire image in a blurry state feels like “almost loaded,” while seeing only the top third of an image feels like “still waiting.”

Impact on Core Web Vitals

Google’s Core Web Vitals measure user experience through three metrics. Progressive JPEG can positively affect two of them:

• Largest Contentful Paint (LCP): LCP measures when the largest content element becomes visible. For baseline JPEG, the browser reports LCP when the image starts rendering (top rows). For progressive, the first scan arrives quickly and renders the full image area (blurry). Both report similar LCP times, but the progressive version shows a more useful preview at that moment.
• Cumulative Layout Shift (CLS): Both progressive and baseline behave identically for CLS — the image dimensions are known from the JPEG header before any pixel data arrives. Neither mode causes layout shift when proper width/height attributes or CSS aspect-ratio are set.
• Interaction to Next Paint (INP): No direct impact from either mode.

Above-the-fold hero images

For large hero images at the top of a page, progressive encoding is especially beneficial. On a 3G mobile connection, a 200 KB hero image takes about 2 seconds to fully load. With progressive encoding, the user sees a recognizable (if blurry) version of the hero after just 200–400 ms — enough to understand the page’s visual identity while the rest of the content continues loading.

Browser Support in 2026

Progressive JPEG enjoys universal browser support. There is no compatibility concern in any modern or even moderately old browser:

Progressive JPEG is part of the original JPEG specification (ITU-T T.81, published in 1992). It has been supported by every major image viewer and browser for decades. There is zero risk of compatibility issues.

Is Progressive Still Relevant in 2026?

With HTTP/2, 5G networks, and broadband speeds measured in hundreds of megabits, one might wonder whether the incremental loading benefit of progressive JPEG still matters. The answer is nuanced.

On fast connections: Minimal visible difference

On a fiber connection or a strong 5G signal, a 200 KB image loads in under 50 ms. At that speed, neither progressive nor baseline shows any visible loading behavior — the image simply appears fully rendered. The user never sees the blurry-to-sharp transition because all scans arrive before the first frame is painted.

On slow connections: Still very relevant

Not everyone has fast internet. In 2026, significant portions of the world still rely on 3G or congested WiFi networks. In these conditions:

• A 300 KB image on a 1 Mbps connection takes about 2.4 seconds.
• With progressive encoding, the user sees a recognizable preview in ~400 ms.
• With baseline encoding, the user sees only the top 15% of the image at 400 ms.

For users on slow connections — rural areas, developing markets, congested public WiFi, underground transit — progressive JPEG provides a meaningfully better experience.

The bottom line: No downside

Progressive JPEG has no disadvantages compared to baseline for images above 10 KB:

• Same or slightly smaller file size.
• Same final image quality.
• Universal browser support.
• Better perceived loading on slow connections.
• No extra encoding time (negligible difference).
• No extra decoding time in browsers.

There is simply no reason to choose baseline over progressive for web images. Progressive is the strictly better default.

How to Create Progressive JPEG

Most image processing tools support progressive encoding. Here are the most common methods:

ImageMagick

ImageMagick uses the -interlace flag to control progressive encoding:

# Progressive JPEG
convert input.png -interlace Plane -quality 85 output.jpg

# Baseline JPEG (explicit)
convert input.png -interlace None -quality 85 output.jpg

The -interlace Plane option tells ImageMagick to write the DCT coefficients in frequency-band order (progressive) rather than block-by-block order (baseline). The quality setting is independent — you can combine any quality level with either interlace mode.

Convertio.com

Our converter uses progressive encoding by default. When you upload a PNG and convert to JPG, the output is always a progressive JPEG. No configuration needed.

Adobe Photoshop

In Photoshop’s “Save for Web” (or “Export As”) dialog, check the “Progressive” checkbox. In the regular “Save As” JPEG dialog, enable “Progressive” in the JPEG Options panel.

GIMP

When exporting as JPEG, expand the advanced options and check “Progressive”. GIMP uses libjpeg under the hood, which fully supports progressive encoding.

jpegtran (Lossless Conversion)

If you have an existing baseline JPEG and want to convert it to progressive without re-encoding (no quality loss at all):

# Convert baseline to progressive (lossless)
jpegtran -progressive input.jpg > output.jpg

# Convert progressive to baseline (lossless)
jpegtran -baseline input.jpg > output.jpg

jpegtran rearranges the DCT coefficients without decoding and re-encoding the image. This is a truly lossless operation — the pixels do not change at all. Only the byte layout in the file changes.

Batch conversion with mogrify

To convert an entire folder of baseline JPEGs to progressive in-place:

# ImageMagick mogrify (overwrites originals)
mogrify -interlace Plane *.jpg

# Or with jpegtran (lossless, to a separate folder)
mkdir -p progressive
for f in *.jpg; do
  jpegtran -progressive "$f" > "progressive/$f"
done

How to Check if a JPEG Is Progressive

You can determine whether an existing JPEG file uses progressive or baseline encoding with several methods:

ImageMagick identify

identify -verbose image.jpg | grep Interlace

This outputs either Interlace: JPEG (progressive) or Interlace: None (baseline).

file command (Linux/Mac)

file image.jpg

For a progressive JPEG, the output includes “progressive” in the description. For baseline, it says “baseline” or does not mention either.

Python (Pillow)

from PIL import Image
img = Image.open("image.jpg")
print("Progressive" if img.info.get("progressive") else "Baseline")

Browser DevTools

Unfortunately, browser DevTools do not directly show whether a JPEG is progressive or baseline. The Network tab shows the file size and download timing, but not the encoding mode. Use one of the command-line methods above for a definitive check.

Progressive JPEG vs Modern Alternatives

In 2026, progressive JPEG competes with newer image formats that have their own progressive-like features:

WebP and AVIF produce significantly smaller files but do not support progressive decoding natively. They load top-to-bottom like baseline JPEG. JPEG XL has an advanced progressive mode that is superior to JPEG’s, but browser support remains limited in 2026.

For maximum compatibility with progressive loading, JPEG remains the only universally supported option. For maximum compression, consider WebP or AVIF with responsive image techniques (<picture> element) that fall back to JPEG for older browsers.