JPG Format: Compression, Quality & Web Use Cases

Origin and adoption

JPEG (Joint Photographic Experts Group) is named after the standards committee that developed it through the late 1980s. The first version of the standard was published in 1992. The format succeeded so completely at its design goal — making photographic images small enough to share over slow connections — that it became the de facto standard for photographic content within years and has held that position for more than three decades.

The .jpg and .jpeg extensions refer to the same format. The three-character .jpg exists because early Windows and DOS filesystems limited extensions to three characters. Some workflows still treat them as distinct; modern tools treat them as identical.

Despite the rise of WebP, AVIF, HEIC, and JPEG XL, JPEG remains the most-deployed image format on the web by orders of magnitude. Every camera, every browser, every operating system, every image editor handles JPEG natively. No other format approaches that universality.

How JPEG compression works

JPEG is a lossy format. The compression pipeline has four stages, each of which discards information the human visual system is least likely to notice.

1. Colour space conversion

The image is converted from RGB to YCbCr — one luminance channel (Y) and two chrominance channels (Cb, Cr). The human eye is much more sensitive to luminance detail than chrominance detail. Separating them allows the encoder to compress the chrominance channels more aggressively without visible loss.

2. Chroma subsampling

The chrominance channels are downsampled, typically by a factor of 2 horizontally and vertically (4:2:0 subsampling). This is the first lossy step and accounts for a significant portion of JPEG's compression. For most photographic content, the loss is invisible.

Quality-conscious encoders sometimes use 4:4:4 (no subsampling) for content with fine colour detail — small coloured text, line art with red on green, hand-drawn illustrations. The trade-off is a larger file.

3. Discrete Cosine Transform (DCT)

The image is divided into 8×8 pixel blocks. Each block is transformed into the frequency domain via the DCT, producing 64 coefficients that represent the spatial frequencies in the block. Low-frequency coefficients (gradual changes) carry most of the visible information; high-frequency coefficients (fine detail) carry less.

4. Quantisation

The DCT coefficients are divided by a quantisation matrix and rounded. The quantisation matrix is the lossy step where the quality factor is applied — higher quality means smaller divisors and more preserved detail; lower quality means larger divisors and more aggressive rounding to zero.

The rounded coefficients are then run-length encoded and Huffman-coded for storage.

The quality factor

JPEG's quality factor runs from 1 to 100. The widely-used values:

q=95–100: archival quality. Files are large. Diminishing returns above q=92.
q=85–94: high-quality web delivery. Visually indistinguishable from the source on typical displays.
q=75–84: standard web delivery. Imperceptible quality loss for almost all viewers.
q=60–74: thumbnail and below-the-fold territory. Some loss visible on close inspection.
q=40–59: aggressive compression. Visible artefacts but acceptable for decorative use.
q=1–39: heavy compression. Generally avoid.

Different JPEG encoders interpret the quality scale slightly differently. A q=80 file from cjpeg is not bit-identical to a q=80 file from Photoshop. The general shape of the quality curve is consistent, but exact byte counts vary.

Progressive vs baseline encoding

JPEG supports two encoding modes:

Baseline — the file is encoded top-to-bottom. Decoders display the image as bytes arrive, showing progressively more rows of the final image.
Progressive — the file is encoded as a sequence of "scans" of decreasing coefficient detail. Decoders display the full image at low fidelity as soon as the first scan arrives, then refine it as later scans load.

Progressive JPEGs are 2–8% smaller than baseline JPEGs at the same quality and produce a better perceived loading experience. Most modern encoders default to progressive. If you're encoding for the web, prefer progressive.

MozJPEG

Mozilla's MozJPEG fork of libjpeg-turbo produces JPEG files that are 10–15% smaller than standard encoders at the same visual quality. The output is bit-compatible with the JPEG standard — any JPEG decoder can read MozJPEG output.

The savings come from better quantisation tables, smarter chroma subsampling decisions, and trellis quantisation for more compact coefficient encoding.

cjpeg -quality 80 -progressive input.png > output.jpg

For any pipeline that still produces JPEGs, MozJPEG is the right encoder.

What JPEG cannot do

JPEG's limitations are the reason every "modern" image format exists:

No transparency. JPEG cannot encode an alpha channel. Content requiring transparency must use PNG, WebP, or AVIF.
No animation. JPEG is a single-frame format. APNG, animated WebP (see GIF to WebP), animated AVIF, or video formats handle motion.
Lossy only. JPEG has no lossless mode. Encoding and re-encoding the same JPEG (each save in an image editor) compounds artefacts.
No HDR. Standard JPEG is 8-bit per channel. HDR content needs newer formats.

These limitations are why JPEG remains the right choice only for one specific case: photographic content displayed once, with no transparency, no animation, no need for editing round-trips.

Modern relevance

JPEG is the safest universal default for photographic content distributed beyond the browser:

Email attachments where format support is patchy.
Social media uploads, where platforms will re-encode anyway.
Press releases and downloadable photo bundles.
Camera output (until newer formats like HEIC and AVIF achieve universal viewer support).
Marketplace product photos (Etsy, eBay, marketplace APIs) where strict format requirements apply.

For browser-delivered photographic content, JPEG has been substantially displaced by WebP (25–35% smaller at equivalent quality) and AVIF (additional 20–30% smaller than WebP). The migration pattern is usually a <picture> element with WebP/AVIF sources and JPEG fallback.

When to encode as JPEG today

Choose JPEG when:

The image is photographic content distributed outside the browser.
You need maximum compatibility with arbitrary third-party tools.
The image will be re-encoded by a downstream service (social platform upload) and any "modern format" advantage will be lost in transcoding.
The platform you're shipping to explicitly requires JPEG.

Choose WebP when:

The image is for browser display.
You control the delivery pipeline.
Page weight matters (which it almost always does).

Choose AVIF when:

The above conditions for WebP apply, AND.
You can tolerate slightly longer encoding time and slightly slower decode on low-end devices in exchange for additional file size savings.

For the systematic mode-choice framework, see Lossy vs Lossless Compression. For migrating an existing JPEG library to WebP, see JPG to WebP.

Avoiding the double-lossy problem

If you encode a JPEG as lossy WebP, you have applied two lossy compression passes on the same content. The second pass cannot recover detail the first pass discarded, and at low qualities the artefacts compound.

Two mitigations:

Encode lossy WebP at q≥80. At this quality, the second pass discards little additional detail. The output is still visually indistinguishable from the JPEG source.
Use lossless WebP only when worthwhile. A JPEG source has artefacts; losslessly preserving them at full lossless file size is pointless.

Detailed guidance in Lossy vs Lossless Compression.

Implementation patterns

For modern web use with progressive enhancement:

<picture>
  <source
    type="image/avif"
    srcset="/img/photo-800.avif 800w, /img/photo-1200.avif 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <source
    type="image/webp"
    srcset="/img/photo-800.webp 800w, /img/photo-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="..."
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

The browser picks the first format it supports. JPEG remains the universal fallback.

Converters

JPG to WebP — convert existing JPG library to WebP
WebP to JPG — convert WebP back to JPG for compatibility