JPEG

What compression changes in JPEG

JPEG encoders first convert images to a luma–chroma colour space such as YCbCr because the human visual system is more sensitive to luminance detail than chrominance. To exploit this, encoders often apply chroma subsampling (commonly 4:2:0 or 4:2:2), reducing colour resolution relative to luma. Pixels are then split into 8×8 blocks and transformed to the frequency domain using the discrete cosine transform (DCT), which concentrates most energy in a few low‑frequency coefficients per block.

Quantisation is the primary lossy step: DCT coefficients are divided by entries in a quantisation table and rounded, discarding fine detail in a perceptually weighted manner. The “quality” setting exposed by most tools scales these tables; lower values apply coarser quantisation, yielding smaller files at the cost of increased distortion. After quantisation, remaining coefficients are run‑length encoded and compressed with entropy coding. Baseline JPEG uses Huffman coding; arithmetic coding is defined in the standard but is rarely used on the web due to legacy patent history and limited tooling.

Baseline JPEG stores each block’s coefficients in one or more scans; progressive JPEG reorganises coefficients across multiple scans so the image refines from coarse to fine as data arrives. Progressive encoding can improve perceived loading but sometimes increases file size slightly. Common artefacts from aggressive compression include 8×8 blocking, ringing near edges, and mosquito noise around high‑contrast details. Encoder features such as trellis quantisation, custom quant tables, and optimised Huffman tables can reduce bitrate at a given perceptual quality.

Typical web use cases

JPEG is well suited to photographic and natural imagery: hero banners, editorial photography, product shots with complex textures, travel and food images, and user‑generated photos. These assets benefit from the format’s ability to compress smoothly varying tone and colour with little visible loss at moderate bitrates. For most websites, the majority of image bytes are still JPEGs because they deliver an acceptable trade‑off between quality, speed, and ubiquitous support across browsers, devices, and email clients.

JPEG is also common for responsive image sets, where multiple sizes are generated to match device pixel density and layout widths. Progressive JPEGs are sometimes preferred for large hero images to present a quick coarse preview that refines as more data is downloaded, which can improve perceived performance on slower connections. Thumbnails and gallery cards often use slightly higher compression because small render sizes mask some artefacts that would be noticeable at full resolution.

JPEG is not ideal for line art, UI screenshots, logos, or text‑heavy graphics where sharp edges and flat colours dominate. Chroma subsampling and DCT quantisation can introduce colour bleeding and edge ringing that is conspicuous on synthetic content. Formats like PNG or SVG (or WebP/AVIF in lossless mode) are typically preferred for transparency, crisp edges, and pixel‑perfect rendering. For images that need partial transparency or animation, alternative formats are required because baseline JPEG does not support alpha or multi‑frame images.

Page weight and bandwidth

Images frequently account for 40–70% of a page’s transferred bytes, and JPEG files are often the largest single contributors. Switching photographic assets from uncompressed or PNG sources to appropriately tuned JPEG can reduce byte sizes by 60–90% depending on content, which can lower time to first render and improve Core Web Vitals. Savings vary with image detail, noise, and intended viewport size; flat graphics compress poorly in JPEG and should be kept in a lossless format instead.

Typical web‑ready JPEGs land in the 0.2–1.5 bits‑per‑pixel range. For many scenes, quality settings roughly equivalent to q70–85 in libjpeg‑style encoders strike a balance between visual fidelity and file size, with diminishing returns above that range. A 2400×1600 photo that might be 1–3 MB as a high‑quality PNG can often be delivered as a 150–350 KB JPEG without obvious artefacts at common display sizes. Metadata removal often shaves an additional 5–50 KB depending on embedded EXIF, XMP, and thumbnails.

Perceived performance also depends on delivery practices. Responsive images (srcset and sizes) limit over‑fetching on small viewports, lazy‑loading defers off‑screen transfers, and HTTP caching reduces repeat costs. Progressive JPEGs can improve visual feedback for large above‑the‑fold images by displaying a recognisable preview early in the connection. On constrained networks or with the Save‑Data preference, serving lower‑quality variants helps reduce bandwidth while keeping content intelligible, especially for image‑heavy feeds and listings.

Compression model

Luma–chroma separation and subsampling

By separating brightness from colour and reducing chroma resolution, JPEG removes information the eye is less sensitive to. 4:2:0 subsampling halves chroma resolution horizontally and vertically and is adequate for natural imagery. However, it can cause colour fringing around fine text or UI elements on coloured backgrounds. For graphics with sharp colour boundaries—or when downsampling will be aggressive—4:4:4 encoding or an alternative format yields cleaner results at similar visual quality targets.

DCT, quantisation, and artefacts

The 8×8 DCT maps spatial patterns into frequency coefficients; low frequencies represent smooth gradients while high frequencies capture edges and texture. Quantisation tables weight these coefficients, preserving low‑frequency content more than high. At lower bitrates this creates visible artefacts: blockiness at 8‑pixel boundaries, ringing halos near edges, and buzzing around sharp details. Modern encoders mitigate artefacts using optimised scan orders, trellis quantisation, and custom tables tuned to typical web imagery, improving efficiency at the same perceived quality relative to older defaults.

Precision and modes

Web JPEGs are overwhelmingly 8‑bit per component. The standard includes 12‑bit lossy and a separate lossless predictive mode, but those are uncommon online and have limited decode support across browsers and libraries. Progressive JPEG is widely supported and can improve perceived loading for large images. Arithmetic coding is part of the specification but remains niche; baseline Huffman‑coded JPEG is the de facto interoperable choice for web delivery and tooling compatibility.

Scope: accessibility and support in browsers and user agents

Accessibility considerations

JPEG’s compression can affect legibility. Heavy quantisation or 4:2:0 subsampling may blur thin lines and colour edges, which is problematic for text baked into images, charts with fine grid lines, or instructional graphics. For accessibility, key information should not depend solely on embedded text within images; provide alt text, captions, and structured data. Colour management also affects readability: embedding an sRGB ICC profile or converting to sRGB helps maintain consistent contrast and hue across devices, reducing the risk of low‑contrast rendering for users with low vision or colour‑vision deficiencies.

Browser and agent support

JPEG decoding is universal across web browsers, operating systems, native apps, and email clients. Progressive JPEG is widely supported. Most web stacks expect 8‑bit YCbCr with JFIF or Exif metadata; CMYK JPEGs and non‑sRGB colour spaces decode in many browsers but can display unpredictably if profiles are missing. Modern browsers generally honour EXIF orientation, but normalising orientation and converting to sRGB during processing reduces surprises in third‑party contexts. Assistive technologies interact with surrounding HTML rather than the JPEG itself, so accessible markup, intrinsic dimensions, and responsive delivery have more impact on user experience than the specific JPEG mode chosen.

Implementation notes

Common practice on the web is to encode photographic assets as 8‑bit, sRGB, 4:2:0 JPEG using a modern encoder such as libjpeg‑turbo or MozJPEG. These encoders provide optimised Huffman tables, trellis quantisation, and progressive scan scripts that lower file size for a given subjective quality relative to legacy defaults. Quality settings near the middle of the available range often deliver good results; visual evaluation at intended display sizes remains the most reliable gauge given the variability of scenes, device pixel densities, and compression artefacts.

Chroma subsampling trades colour detail for bytes. For portraits, landscapes, and product photos without small coloured text, 4:2:0 is efficient and visually safe. For UI screenshots, infographics, or assets with saturated micro‑detail, 4:4:4 JPEG or a lossless format maintains edge fidelity. Metadata can add measurable overhead; it is common to retain only ICC profiles (for consistent colour) and necessary EXIF tags while stripping thumbnails and camera data to reduce transfer size and avoid inadvertently exposing sensitive capture details such as GPS coordinates.

Pipeline decisions influence final quality. Repeatedly recompressing JPEGs compounds artefacts, so maintaining a high‑quality master (for example, TIFF or PNG) and generating derivatives per breakpoint avoids cumulative loss. Responsive images via srcset and sizes limit over‑fetching, while including width and height attributes reserves layout space to prevent cumulative layout shift. Content negotiation can serve next‑gen formats when supported and fall back to JPEG, preserving broad compatibility without forcing the lowest common denominator for every client.

Comparisons

JPEG remains a baseline for photographic content, but other formats can outperform it in specific scenarios. Trade‑offs include compression efficiency, transparency, animation, decode speed, and tooling maturity. The choice often depends on user agent support targets, CPU budgets on low‑end devices, and operational complexity in pipelines and CDNs.

• WebP (lossy): Typically 20–35% smaller than like‑for‑like JPEG at similar quality for many photos, with optional alpha and animation. Decode speed is good and support is broad. JPEG remains faster to encode and is universally compatible, including legacy clients and email.
• AVIF (lossy): Often 30–50% smaller than JPEG for equal subjective quality, with better retention of edges and film grain. Decode is more CPU‑intensive and encoding is slower, which can affect on‑the‑fly generation at scale. Support is strong across modern browsers, but JPEG still provides the widest reach.
• JPEG XL: Designed as a modern successor with high efficiency, lossless mode, progressive refinement, and features like wide gamut and high bit depth. Browser support is emerging and not universal, so production use often requires fallbacks; JPEG remains the dependable baseline for universal delivery.
• PNG: Lossless and ideal for graphics, UI, and images requiring transparency. For photos, PNGs are typically several times larger than JPEG. Indexed‑colour PNGs compress flat graphics well, but photographic content benefits more from JPEG or other lossy formats.
• HEIC/HEIF: Efficient and feature‑rich, commonly used in mobile ecosystems for capture. Web support is limited compared with JPEG, WebP, and AVIF. Converting HEIC uploads to web‑friendly formats is common in publishing workflows.

FAQs

What JPEG quality is suitable for the web?

There is no universal value because scenes vary, but mid‑range settings (roughly q70–85 in libjpeg‑style scales) usually balance fidelity and size. Evaluate at the intended render size, because oversharpening and downscaling can mask or reveal artefacts. Modern encoders such as MozJPEG tend to achieve smaller files at the same perceived quality than legacy defaults at the same nominal “quality” number.

Should I use progressive or baseline JPEG for the web?

Progressive JPEG is widely supported and can improve perceived loading for large above‑the‑fold images by rendering a coarse preview quickly. It may be marginally larger than baseline for some images, and the benefit is smaller on very fast connections. For small images or thumbnails, the difference is negligible; for large photographic heroes, progressive often enhances user perception without compatibility issues.

Does JPEG support transparency or animation?

Standard JPEG does not support an alpha channel or multiple frames. If transparency or animation is required, consider WebP or AVIF (both support alpha and animation) or use PNG for lossless transparency. Some container tricks exist (for example, JPEG in MJPEG video or composite formats), but they are not interoperable for general web delivery.

Why do JPEG colours look different across devices or browsers?

Colour management and profiles are the usual causes. If an image is encoded in a wide‑gamut or CMYK space without an embedded ICC profile, browsers may assume sRGB and display incorrect hues or saturation. Converting assets to sRGB and embedding an ICC profile where appropriate produces more consistent results. Variations in display calibration and tone mapping also influence perceived colour and contrast.

Can JPEG be lossless on the web?

The JPEG family includes a lossless predictive mode and 12‑bit sample support, but these modes are rarely used online and have patchy decode support. Most web JPEGs are 8‑bit lossy encodes. Where exact pixel preservation is required, PNG or lossless WebP/AVIF are typically chosen instead of lossless JPEG modes.