Progressive JPEG vs Baseline JPEG - Which Should You Use?

Progressive JPEG and baseline JPEG store the same kind of JPEG image data, but they load differently. Baseline JPEG paints from top to bottom. Progressive JPEG shows a blurry full-image preview first, then sharpens it in passes. For most web JPEG fallbacks, progressive JPEG is the better default.

TL;DR: Use progressive JPEG for most JPEG images over tiny-thumbnail size. It usually feels faster because users see the whole image early, and it is often slightly smaller than baseline JPEG. Use baseline JPEG only for very small images, legacy workflows, or cases where decode simplicity matters. For modern websites, serve WebP or AVIF first and keep progressive JPEG as the fallback through a <picture> element or image CDN format negotiation.

Which Is Better: Progressive or Baseline JPEG?

For normal web images, progressive JPEG is usually better.

The important word is "fallback."

If a browser supports WebP or AVIF, those are usually better delivery formats than either JPEG encoding. The WebP vs AVIF vs JPEG guide covers that broader decision.

Progressive JPEG still matters because JPEG is not dead. HTTP Archive's 2024 Media chapter reported JPEG at 32.4% of mobile image resources. Many sites still need JPEG fallbacks, email images, CMS uploads, and legacy support.

How Do Progressive and Baseline JPEG Load?

Both are JPEG. Both use lossy JPEG compression. The difference is how the compressed data is arranged and decoded during download.

Baseline JPEG

Baseline JPEG loads sequentially.

The browser receives enough bytes for the top part of the image, decodes those rows, and paints them at final quality. The rest of the image stays blank until more data arrives.

On a slow connection, this creates the classic loading pattern:

1. The top rows appear sharp.
2. The visible part grows downward.
3. The bottom remains empty until later.

This is simple and fast to decode.

Progressive JPEG

Progressive JPEG loads in scans.

The first scan gives the browser enough information to show a rough full-image preview. Later scans add more detail until the final image is sharp.

On a slow connection, this creates a different loading pattern:

1. A blurry full image appears early.
2. The full composition is visible.
3. Detail sharpens over time.

web.dev's JPEG guide explains the difference clearly: baseline JPEG renders top to bottom, while progressive JPEG breaks rendering into full-size scans that increase image quality.

For users, progressive loading often feels better because empty space is replaced with a usable preview.

Why Can Progressive JPEG Be Smaller?

This surprises people.

Progressive JPEG is not always larger. It is often slightly smaller than baseline JPEG.

web.dev says that except for the smallest images, encoding as progressive JPEG almost always means a smaller file than baseline JPEG. Mozilla's mozjpeg team also notes that mozjpeg creates progressive JPEGs by default because those files tend to be about 4% smaller than baseline JPEGs.

The reason is entropy coding.

Progressive JPEG groups similar frequency information across scans. That can make the Huffman coding more efficient than storing all coefficient types together in one baseline sequence.

Do not oversell the savings. Progressive JPEG is not a 30% win. It is usually a small file-size improvement plus a perceived-loading improvement.

For larger wins, convert to WebP or AVIF where browser support allows.

Does Progressive JPEG Improve Performance?

It improves perceived performance more than lab metrics.

The LCP detail matters.

Largest Contentful Paint generally cares when the final image is rendered as the largest element. A blurry intermediate scan usually does not give you full LCP credit by itself. So progressive JPEG is not an LCP hack.

It can still help the page feel faster. On slower networks, a blurry full preview is better than blank space or a half-painted image.

The decode tradeoff is real but usually acceptable. Progressive JPEG is more complex for browsers to decode than baseline JPEG. On normal modern devices, this is rarely the bottleneck. On very low-end hardware, baseline may be safer for small images.

Progressive JPEG vs WebP and AVIF

Progressive JPEG is not the main image optimization decision in 2026.

The better stack is:

1. AVIF when supported and useful.
2. WebP as the practical modern fallback.
3. Progressive JPEG as the universal JPEG fallback.

Example:

<picture>
  <source srcset="/images/product.avif" type="image/avif" />
  <source srcset="/images/product.webp" type="image/webp" />
  <img
    src="/images/product.jpg"
    alt="Black leather office chair"
    width="1200"
    height="800"
    loading="lazy"
  />
</picture>

In that setup, product.jpg should usually be progressive if it is a medium or large JPEG.

If you use an image CDN, the CDN can read the Accept header and choose the right format automatically. That is simpler than maintaining every variant yourself. See can image CDNs convert image formats?.

When Should You Use Baseline JPEG?

Baseline JPEG still has a place.

Use baseline when:

• the image is tiny
• the file is an email asset with strict compatibility needs
• an old toolchain expects baseline JPEG
• you are optimizing for the simplest decode path
• progressive overhead makes the file larger

For tiny thumbnails, progressive JPEG can add overhead from multiple scans and tables. If the image is only a few kilobytes, the preview benefit is not meaningful anyway.

For most content images, use progressive.

How Do You Create Progressive JPEGs?

jpegtran

This converts an existing JPEG to progressive without changing image pixels.

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

Use this when you already have JPEG files and want to change the encoding structure without a full quality-lossy re-export.

MozJPEG

MozJPEG creates progressive JPEGs by default.

cjpeg -quality 80 input.png > output.jpg

Use -baseline only if you deliberately want baseline output.

ImageMagick

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

-interlace Plane is the common setting for progressive JPEG output.

Python Pillow

from PIL import Image

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

Squoosh

Squoosh lets you enable progressive rendering in JPEG settings. It is useful for quick manual tests, not for a full production image pipeline.

Do Image CDNs Support Progressive JPEG?

Many image CDNs can output optimized JPEG fallbacks, but their main value is broader than progressive JPEG.

A good CDN setup can:

• serve AVIF to browsers that support it
• serve WebP as the next fallback
• serve optimized JPEG for older browsers
• resize images by viewport
• cache variants at the edge
• preserve stable URLs

That means the progressive-vs-baseline decision becomes smaller. It only applies to visitors who receive JPEG.

Still, your JPEG fallback should be good. For large fallback images, progressive JPEG is usually the right choice.

For provider selection, start with best image CDNs, free image CDNs, or paid CDN options.

Common Mistakes

1. Treating progressive JPEG as a replacement for WebP

It is not. Progressive JPEG is still JPEG. WebP and AVIF usually give larger file-size savings.

2. Lazy-loading the LCP image

Progressive JPEG cannot fix a hero image that starts loading too late. Do not lazy-load your above-the-fold LCP image.

3. Forgetting image dimensions

Use width and height. Progressive loading does not prevent layout shift by itself.

4. Using progressive JPEG for tiny images

For tiny thumbnails, baseline can be smaller and simpler.

5. Re-exporting JPEGs repeatedly

If you re-save a JPEG through a lossy encoder again and again, quality degrades. Use jpegtran when you only need baseline-to-progressive conversion.

Summing Up!

Use progressive JPEG for most medium and large JPEG fallback images. It usually gives a slightly smaller file and a better perceived loading experience because users see a blurry full-image preview before the final sharp image arrives.

Use baseline JPEG for tiny images, strict legacy workflows, or cases where the simplest decode path matters.

For a modern website, the bigger win is format negotiation: AVIF first, WebP second, progressive JPEG fallback. An image CDN can handle that automatically while also resizing and caching variants for each browser.