Every JPEG is stored in one of two layouts: baseline or progressive. They contain exactly the same pixels and decode to the same image, but they organise the compressed data in fundamentally different orders. That single difference changes how the image appears while it loads, how big the file is, and how much memory a browser needs to decode it. Understanding the trade-off helps you pick the right layout for web performance rather than leaving it to whatever default your tools happen to use.
Both layouts are supported by the optimise JPEG tool, which lets you convert between them in one click without any quality loss.
How Baseline JPEG Works
A baseline JPEG stores the image in a single top-to-bottom pass. The encoder walks the image in 8×8 blocks, left to right and top to bottom, writing each block's compressed coefficients in order. When a browser decodes it, the picture paints in from the top like a window blind being lowered. On a slow connection you see a sharp top portion and an empty lower portion until the download finishes.
Baseline is simple, universally supported, and slightly cheaper to decode because the decoder can render each block the moment it arrives. For very small images — icons, tiny thumbnails — it is often the better choice, since there is no perceptible loading sequence anyway and it avoids any per-scan overhead.
How Progressive JPEG Works
A progressive JPEG stores the same coefficients but reorganised into multiple scans. The first scan carries a coarse, full-frame approximation; each subsequent scan adds detail across the whole image at once. As the file downloads, the viewer sees the entire picture appear blurry and then sharpen, rather than painting top-to-bottom.
This reordering is achieved by separating the DCT coefficients by frequency and by significance, then grouping them into successive scans — techniques known as spectral selection and successive approximation. Crucially, this reorganisation is lossless: no pixel data is changed when you convert a baseline JPEG to progressive. The decoded result is byte-for-byte identical in appearance.
The File-Size Difference
Progressive JPEGs are usually, though not always, smaller than their baseline equivalents. The reason lies in the entropy-coding stage. Grouping similar-frequency coefficients together creates longer runs of similar values, which Huffman coding compresses more efficiently. For typical web photos the saving is a few percent. For some images there is no difference at all, and for very small files progressive can occasionally be slightly larger because each scan carries a little fixed overhead. The only way to know for a given image is to try both and keep the smaller one.
Side-by-Side Comparison
- Loading appearance: Baseline paints top-to-bottom; progressive fades in whole-image and sharpens.
- File size: Progressive is usually a few percent smaller; baseline can win on tiny images.
- Decode cost: Baseline is cheaper; progressive needs the whole file and more memory before its final render.
- Perceived speed: Progressive feels faster on large images because content becomes recognisable sooner.
- Compatibility: Both decode everywhere, so this is not a compatibility decision.
Which One Should You Use?
For most web photography above roughly 10 KB, progressive is the better default. The whole-image preview makes the page feel faster, and you usually get a small size bonus as a bonus. For tiny images — icons, sprites, sub-10 KB thumbnails — baseline avoids the per-scan overhead and decodes with less work. There is one caveat worth knowing: a progressive JPEG requires the entire file before its final sharp render, so it can use more memory during decode, which matters on very large images or low-end devices.
How to Convert Between the Two
Switching layouts is quick and risk-free because it is lossless:
- Open the optimiser. Load the optimise JPEG tool.
- Add your JPEG. Drag in the image you want to re-lay-out.
- Choose progressive. Enable the progressive option; because it is lossless, quality is unaffected.
- Compare sizes. Note the before and after byte counts and keep whichever is smaller for your case.
- Download. Save the re-encoded file and deploy it.
Because the conversion changes no pixels, it pairs perfectly with the other lossless techniques covered in lossless JPEG optimisation. And to understand the DCT coefficients that get reordered into scans, see JPEG compression explained.
Progressive and Perceived Performance
Because a progressive image becomes recognisable sooner, it can improve perceived loading even when it does not change the final paint timing dramatically. The measurement nuances — and why your Largest Contentful Paint metric may or may not move — are covered in images and Core Web Vitals. For an even bigger leap in efficiency, modern formats encode progressively by nature and tend to be smaller; compare them in JPEG versus WebP and try the JPEG to WebP tool. If you simply want a quick smaller progressive file, the compress JPEG tool will do it in one step.
A Closer Look at Scans
To appreciate why progressive looks the way it does, it helps to understand what a scan contains. The very first scan typically carries only the DC coefficients — the single average value of each 8×8 block. That is enough to reconstruct a heavily pixelated but recognisable version of the whole image almost instantly. Each later scan then refines the picture by adding bands of AC coefficients, from low frequency to high.
Successive approximation goes further by sending the most significant bits of each coefficient first and the finer bits later. The combined effect is that a viewer sees structure, then broad detail, then fine texture, in that order. This ordering matches how humans actually perceive an image: we recognise the subject from its rough shapes long before we notice the texture of a fabric or the individual leaves on a tree.
Practical Recommendations by Image Type
Rather than applying one rule everywhere, match the layout to the role each image plays:
- Hero and banner images: Use progressive. They are large, above the fold, and benefit most from an early recognisable preview.
- Gallery and content photos: Use progressive, and lean on the small size bonus across many images.
- Icons, sprites, and tiny thumbnails: Use baseline to avoid per-scan overhead on files where loading order is invisible.
- Memory-constrained contexts: Consider baseline for very large images on low-end devices, since progressive needs the whole file in memory before its final render.
Because the conversion is lossless, you can confidently test both layouts on any image and simply keep whichever is smaller, with no risk to quality.
One more practical point: many image editors default to baseline when exporting, so a large fraction of the JPEGs already on the web are baseline simply because nobody changed the setting. That means there is often a free, lossless win waiting in your existing library. Re-encoding those photos to progressive can shave a few percent across the board and improve how they feel while loading, all without any visible change to the images themselves.
Conclusion
Baseline and progressive JPEGs hold identical pixels but load very differently. Progressive usually wins for web photos thanks to its whole-image preview and small size bonus, while baseline suits tiny images. The choice is lossless either way, so experiment freely with the optimise JPEG tool at jpegoptim and pick the smaller, faster-feeling result for each image.