Progressive JPEG vs Baseline JPEG — How They Load and Which Is Better

Progressive JPEGs show a blurry full-image preview that sharpens in passes. Baseline JPEGs render top-to-bottom, line by line. But the more surprising fact: progressive JPEGs are also smaller — typically 1–4% smaller than baseline for images over 10 KB, thanks to more efficient Huffman coding.

TL;DR: For images over 10 KB, progressive JPEG is the better default. A study of 10,000 images found progressive encoding produced smaller files 94% of the time. It also improves perceived load speed — users see the full image immediately as a blurry preview that sharpens, instead of watching it paint top-to-bottom. The trade-off is ~3x more CPU for decoding, which is negligible on modern devices. Use baseline only for tiny thumbnails under 10 KB.

How Baseline JPEG Loads

Baseline JPEG uses single-pass, sequential decoding. The image is divided into 8×8 pixel blocks called MCUs (Minimum Coded Units). Each block's 64 DCT coefficients are encoded completely — all frequency data from low to high — then the encoder moves to the next block, left to right, top to bottom.

On a slow connection, the result is the familiar top-to-bottom paint:

1. The browser receives and decodes the first rows of MCUs
2. Those rows render at full quality immediately
3. The rest of the image remains blank
4. Rendering continues downward as more data arrives

Baseline uses a single Huffman table for the entire image and can decode row by row — meaning it needs memory for only a few MCU rows at a time, not the entire image.

How Progressive JPEG Loads

Progressive JPEG encodes the same image data in multiple "scans" — typically 10 scans, though encoders allow 3–13. Each scan covers the entire image but contains different frequency information.

Two techniques make this work:

Spectral selection controls which DCT coefficient indices (0–63) appear in each scan. The first scan transmits only DC coefficients (index 0) — the average color of each 8×8 block. This produces a very blocky, pixelated preview using roughly 1/64th of the data. Later scans add AC coefficients in frequency bands: low-frequency first (gradual gradients), then high-frequency (sharp edges and fine detail).

Successive approximation sends coefficients at reduced bit precision first, then refines them in later scans. Instead of the full 8-bit value, the first scan might send only the top 4 bits, with subsequent scans filling in the remaining precision.

A typical scan structure looks like this:

The key advantage: each scan gets its own optimized Huffman table. Since similar-frequency coefficients across all blocks are grouped together, the entropy coding is more efficient than baseline's single-table approach. This is why progressive files are actually smaller.

For the underlying compression concepts, see the lossy vs lossless compression guide.

File Size: Progressive Is Smaller, Not Larger

This is the most widely misunderstood fact about progressive JPEG. Progressive encoding produces smaller files than baseline for the vast majority of web images.

The Data

Stoyan Stefanov's study (10,000 images):

• For images over 10 KB, progressive was smaller in 94% of cases
• Median reduction: ~3%
• Savings ranged up to 10% for some images

MozJPEG (Mozilla's optimized JPEG encoder) defaults to progressive encoding specifically because progressive files are ~4% smaller than baseline at the same quality setting.

Google's web.dev confirms: "Except for the smallest images, encoding an image as PJPEG almost always means a smaller file size compared to a baseline JPEG."

Why Progressive Is Smaller

Each scan in a progressive JPEG contains coefficients at similar frequencies across all blocks. Grouping similar values together produces better entropy coding — the Huffman tables for each scan are more efficient than baseline's single table that must handle all frequencies mixed together.

The Exception: Images Under 10 KB

For very small images (thumbnails, tiny icons), progressive's structural overhead — multiple scan headers, multiple Huffman tables — can add 1–2 KB that outweighs the compression benefit. Below 10 KB, baseline is often the better choice.

Perceived Performance: What Users Experience

Progressive JPEG's biggest advantage isn't file size — it's how loading feels.

Speed Index Improvements

Pat Meenan (creator of WebPageTest) tested progressive JPEG across the Alexa top 2,000 e-commerce sites and measured Speed Index improvements of:

• 7% on Cable (5 Mbps)
• 15% on DSL (1.5 Mbps)

The improvement scales with connection speed — the slower the connection, the more progressive rendering helps.

A/B Test Results

An A/B test with 10,000 users comparing progressive vs baseline JPEG loading (same total load time) found, according to Elementor:

• 19% improvement in perceived speed
• 23% improvement in user satisfaction
• 44% improvement in bounce rate

These metrics improved despite identical actual load times — the perception of seeing a full (blurry) image immediately beats watching a sharp image paint from the top down.

When It Matters Most

Progressive rendering makes the biggest difference on:

• Slow mobile connections (3G, spotty 4G) where image downloads take 2–5 seconds
• Large above-the-fold images (hero images, product shots) where users stare at the loading area
• Image-heavy pages where multiple large JPEGs compete for bandwidth

On fast connections (fiber, WiFi), both baseline and progressive load so quickly that the rendering difference is imperceptible.

Decoding Performance Trade-offs

Progressive's compression advantage comes with a CPU trade-off.

According to Google's research, decoding a progressive JPEG is roughly equivalent to decoding the baseline image 3 times in CPU cost. Progressive decoding also requires holding the entire image's coefficient data in memory — about 6 bytes per pixel, or ~12 MB for a 1920×1080 image.

In practice, this overhead is negligible on modern devices. Google's web.dev describes it as "very minor and unlikely to be noticeable except for with severely underpowered devices." On 2020+ smartphones and any desktop hardware, the 25ms difference in decode time is invisible.

Quick Note: You can reduce decoding overhead by using fewer scans (2–3 instead of 10). This retains the perceived performance benefit of showing a full preview while cutting CPU cost. Cloudinary calls this "semi-progressive" encoding.

Core Web Vitals: Does Progressive Help SEO?

The short answer: not directly — but it helps indirectly.

LCP (Largest Contentful Paint)

LCP measures when the image is fully rendered, not when intermediate progressive scans appear. A progressive JPEG and a baseline JPEG of identical file size produce the same LCP score. There's an active W3C proposal to reward progressive loading in LCP scoring, but as of March 2026, this hasn't been implemented.

Since progressive files are typically 1–4% smaller, they do finish downloading slightly faster — which gives a marginal LCP improvement from the smaller file size, not from the progressive rendering itself.

CLS (Cumulative Layout Shift)

No difference. Both formats include image dimensions in the header, so the browser reserves the correct space before any pixel data arrives.

INP (Interaction to Next Paint)

Progressive's ~3x decode CPU could theoretically affect INP on extremely slow devices, but this is negligible in practice.

The Real SEO Benefit

Progressive JPEG improves perceived performance, which reduces bounce rates and increases engagement. These behavioral signals do influence rankings — a user who stays on the page because they saw a preview is worth more to Google than one who bounced because the image area was blank. The can image CDNs hurt SEO guide covers CDN-specific SEO implications.

How to Create Progressive JPEGs

jpegtran (Lossless Conversion)

Converts an existing JPEG from baseline to progressive without re-encoding or quality loss:

jpegtran -copy none -optimize -progressive -outfile output.jpg input.jpg

MozJPEG (Progressive by Default)

Mozilla's optimized encoder defaults to progressive. No flag needed:

cjpeg -quality 80 input.png > output.jpg

Use -baseline to force baseline output if needed.

ImageMagick

magick convert -strip -interlace Plane -quality 80 input.jpg output.jpg

Use -interlace Plane for progressive. Note: -interlace JPEG in ImageMagick actually produces baseline output despite the name.

Python (Pillow)

from PIL import Image

img = Image.open("input.jpg")
img.save("output.jpg", "JPEG", quality=80, progressive=True)

Photoshop

File → Export → Save for Web → JPEG → check "Progressive." Photoshop offers 3–5 scan passes.

CDN Support for Progressive JPEG

Most image CDNs prioritize serving WebP or AVIF over JPEG entirely, making the progressive vs baseline question less relevant when a CDN is in the pipeline. For JPEG fallback scenarios:

The broader point: if you're using an image CDN, it's already serving WebP (25–34% smaller than JPEG) or AVIF (up to 50% smaller) to 96%+ of browsers. Progressive vs baseline only matters for the small percentage of visitors receiving JPEG fallback.

Web Usage: How Many JPEGs Are Progressive?

Progressive adoption has grown significantly:

• 2012: ~7% of JPEGs were progressive (Performance Calendar)
• 2023: ~30% of JPEGs on popular websites use progressive encoding (ACM research)

The jump is largely attributed to MozJPEG's adoption — since it defaults to progressive, any pipeline using MozJPEG produces progressive output automatically. JPEG overall still accounts for 32% of all web images as of 2024, though it's declining as WebP and AVIF grow.

Frequently Asked Questions

Is progressive JPEG larger than baseline?

No — the opposite. For images over 10 KB, progressive JPEG is typically 1–4% smaller than baseline. A study of 10,000 images found progressive was smaller 94% of the time. The compression benefit comes from more efficient Huffman tables when similar-frequency coefficients are grouped together.

Does progressive JPEG improve Core Web Vitals?

Not directly. LCP measures full image render, not intermediate scans. But progressive files are slightly smaller (faster download) and reduce bounce rates through better perceived performance — both of which help rankings indirectly.

Can I convert baseline JPEG to progressive without quality loss?

Yes. jpegtran -progressive converts between baseline and progressive losslessly — no re-encoding, no quality degradation. The pixel data stays identical; only the byte ordering changes.

Should I use progressive JPEG or WebP?

WebP is 25–34% smaller than JPEG (progressive or baseline) and should be the primary format for modern browsers. Progressive JPEG matters as a fallback for the ~4% of browsers that don't support WebP. An image CDN handles this automatically.

Does progressive JPEG use more CPU to decode?

Yes — roughly 3x the CPU of baseline decoding. On modern devices (2020+), this adds ~25ms to rendering a 1920×1080 image, which is imperceptible. On very old or low-end mobile devices, the difference could be noticeable.

How many scans should a progressive JPEG have?

The default is 10 scans, but 2–3 scans provide the perceived performance benefit with less decoding overhead. Cloudinary's "semi-progressive" mode uses fewer scans as a practical middle ground.

Summing Up!

Progressive JPEG is the better default for web images over 10 KB. It produces smaller files, improves perceived loading speed, and renders a full (blurry) preview instantly instead of painting top-to-bottom. The only trade-off — ~3x decode CPU — is irrelevant on modern hardware.

That said, the progressive vs baseline debate matters less in 2026 than it did in 2012. An image CDN like BunnyCDN serves WebP or AVIF to 96%+ of visitors, making JPEG format a fallback concern. Use coupon THEWPX for $5 free credit.