# Progressive JPEG vs Baseline JPEG - Which Should You Use? > Progressive JPEG shows a blurry full-image preview before sharpening. Baseline JPEG paints top to bottom. Learn which JPEG encoding is better for web images and fallbacks. _Source: https://theimagecdn.com/docs/progressive-jpeg-vs-baseline-jpeg_ _Published: 2025-08-30 · Updated: 2026-05-24 · By Sunny Kumar_ 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 `` element or [image CDN format negotiation](https://theimagecdn.com/docs/can-image-cdn-convert-formats). - [Fast Answer](#which-is-better-progressive-or-baseline-jpeg) — The practical recommendation by use case. - [How They Load](#how-do-progressive-and-baseline-jpeg-load) — Top-to-bottom paint vs blurry full-image scans. - [Performance](#does-progressive-jpeg-improve-performance) — File size, perceived speed, LCP, and decode tradeoffs. - [How To Create](#how-do-you-create-progressive-jpegs) — jpegtran, mozjpeg, ImageMagick, Pillow, and CDN options. > **Modern Web Context** > > Progressive JPEG is a JPEG fallback optimization. It is useful, but it is not a replacement for serving WebP or AVIF to browsers that support them. The best setup is AVIF/WebP first, progressive JPEG fallback. > **CDN Shortcut** > > An image CDN can serve WebP or AVIF to modern browsers and optimized JPEG fallback when needed. BunnyCDN Optimizer can handle format conversion, and coupon **THEWPX** gives $5 free credit through [this signup link](https://try.sunnysah.com/BunnyCDN). --- ## Which Is Better: Progressive or Baseline JPEG? For normal web images, progressive JPEG is usually better. | Situation | Better choice | Why | | --- | --- | --- | | Large hero image fallback | **Progressive JPEG** | Users see a full preview sooner | | Product photo fallback | **Progressive JPEG** | Better perceived loading on slower networks | | Blog image fallback | **Progressive JPEG** | Good default for medium/large JPEGs | | Tiny thumbnails/icons | **Baseline JPEG** | Progressive overhead can outweigh benefits | | Very old or constrained devices | **Baseline JPEG** | Simpler decode path | | Modern optimized site | **AVIF/WebP first, progressive JPEG fallback** | Better than choosing JPEG alone | 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](https://theimagecdn.com/docs/webp-vs-avif-vs-jpeg) covers that broader decision. Progressive JPEG still matters because JPEG is not dead. HTTP Archive's [2024 Media chapter](https://almanac.httparchive.org/en/2024/media) 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](https://web.dev/learn/images/jpeg) 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](https://web.dev/learn/images/jpeg) 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. | Area | Progressive JPEG impact | | --- | --- | | **File size** | Often slightly smaller than baseline | | **Perceived loading** | Better, because a full preview appears early | | **LCP** | Usually only helped by smaller final bytes, not by intermediate scans | | **CLS** | No direct difference; use `width` and `height` | | **Decode CPU** | Higher than baseline | | **User experience on slow networks** | Usually better for large visible images | 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: ```html Black leather office chair ``` 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?](https://theimagecdn.com/docs/can-image-cdn-convert-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. ```bash 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. ```bash cjpeg -quality 80 input.png > output.jpg ``` Use `-baseline` only if you deliberately want baseline output. ### ImageMagick ```bash magick input.jpg -strip -interlace Plane -quality 80 output.jpg ``` `-interlace Plane` is the common setting for progressive JPEG output. ### Python Pillow ```python 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](https://theimagecdn.com/docs/best-image-cdns), [free image CDNs](https://theimagecdn.com/docs/free-image-cdns), or [paid CDN options](https://theimagecdn.com/docs/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. --- ## Frequently asked questions ### What is a progressive JPEG? A progressive JPEG is a JPEG that loads in multiple full-image scans. The first scan shows a rough full preview, and later scans sharpen the image. It is still a normal JPEG file, just arranged differently from baseline JPEG. ### What is a baseline JPEG? A baseline JPEG is the standard sequential JPEG encoding. It loads from top to bottom as bytes arrive. The visible part appears at final quality, while the rest stays blank until more data downloads. ### Is progressive JPEG smaller than baseline JPEG? Often, yes. web.dev says progressive JPEG is almost always smaller than baseline except for the smallest images. Mozilla's mozjpeg team says progressive JPEGs tend to be about 4% smaller than baseline JPEGs. ### Does progressive JPEG improve LCP? Not directly in the way people often assume. LCP generally waits for the final rendered image, not the blurry intermediate scan. Progressive JPEG can still help slightly if the final file is smaller and can improve perceived loading. ### Can I convert baseline JPEG to progressive without quality loss? Yes. `jpegtran -progressive` can change the JPEG structure without re-encoding the image pixels. That avoids extra JPEG generation loss. ### Should I use progressive JPEG or WebP? Use WebP or AVIF first when the browser supports them. Use progressive JPEG as the JPEG fallback. Progressive JPEG is useful, but it is not as strong as moving to modern image formats. ### Is progressive JPEG bad for CPU? It costs more CPU to decode than baseline JPEG, but this is rarely noticeable on modern devices. For very small images or old low-power devices, baseline can still be a reasonable choice. ## 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](https://theimagecdn.com/docs/best-image-cdns) can handle that automatically while also resizing and caching variants for each browser. ## Sources - [web.dev explains that baseline JPEGs render top to bottom, while progressive JPEGs render full-size scans that increase in quality.](https://web.dev/learn/images/jpeg) - [web.dev says progressive JPEG is almost always smaller than baseline JPEG except for the smallest images.](https://web.dev/learn/images/jpeg) - [Mozilla Hacks says mozjpeg produces progressive JPEGs by default because their file sizes tend to be about 4% smaller than baseline JPEGs.](https://hacks.mozilla.org/2014/08/using-mozjpeg-to-create-efficient-jpegs/) - [HTTP Archive's 2024 Media chapter reported JPEG at 32.4% of mobile image resources.](https://almanac.httparchive.org/en/2024/media)