JPG is the photographic baseline of the web — the format AVIF is built to replace for delivery while still serving as its safest fallback. Published as a standard in 1992, the Joint Photographic Experts Group format reaches effectively 100% of devices, browsers, and editors, a reach no newer codec matches. This page explains why JPG endures, where its 1992 design limits it, how AVIF saves roughly half the bytes at matched quality, and how to migrate without abandoning JPG masters.
Convert between JPG and AVIF in your browser, with no upload: Convert JPG to AVIF and Convert AVIF to JPG.
Why JPG became the universal baseline
JPG is the most widely supported image format ever shipped. The standard was published by the ISO/IEC and ITU-T joint committee in 1992. Three properties cemented its dominance:
- JPG uses the Discrete Cosine Transform, a lossy method tuned to human vision.
- JPG decodes in a few milliseconds on hardware from the last 30 years.
- JPG carries no licensing friction, so every vendor implemented it.
The result is total ubiquity. Every digital camera writes JPG. Every browser, operating system, and image editor reads it natively. AVIF reaches about 94% of users in 2026, per caniuse; JPG reaches the remaining tail that AVIF cannot. That gap is exactly why JPG remains the default fallback in a <picture> element.
How JPG compression works
JPG discards detail the human eye is least likely to notice. The lossy pipeline runs in four stages on each image:
- Colour transform — RGB is converted to YCbCr, separating brightness from colour.
- Chroma subsampling — colour channels are halved in resolution, typically 4:2:0.
- Discrete Cosine Transform — each 8×8 pixel block becomes 64 frequency coefficients.
- Quantisation — coefficients are divided by a quality matrix and rounded toward zero.
The quantisation step is where the quality factor (1–100) acts. A higher factor keeps more coefficients; a lower factor zeroes more of them. AVIF replaces this whole pipeline with the AV1 transform set described on the AVIF format pillar, which is why AVIF compresses harder at the same perceived quality.
The four limits of the 1992 design
JPG's constraints are the reason every modern format exists. Four limits matter most for the web:
- No alpha channel. JPG cannot store transparency; cut-outs need PNG or AVIF.
- 8-bit only. JPG stores 256 levels per channel, so smooth gradients band visibly.
- Generational loss. Each re-save re-quantises the image, compounding artefacts.
- Blocking artefacts. Aggressive quality factors expose the 8×8 DCT grid as visible squares.
These limits are structural, not tuning problems. Banding and blocking are products of 8-bit depth and 8×8 blocks. AVIF answers all four: 10-bit and 12-bit depth, full alpha, larger adaptive transform blocks, and grain synthesis that smooths noisy gradients. See AVIF vs JPG for matched-quality test images.
How much smaller AVIF is than JPG
AVIF stores a photograph in roughly 50% of the bytes of a JPG at the same visual quality. The figure comes from independent 2025–2026 testing:
- Netflix engineering measured AVIF near half the size of JPG at matched perceptual quality.
- An Uploadcare 2025 comparison reported AVIF quality 75 beating JPG quality 85 while landing 40–50% smaller.
The savings widen on gradients, skin tones, and dark scenes, where JPG's 8-bit blocks struggle. They narrow near lossless (q≈90+), where every codec converges. For the parameters behind these results, read AVIF Compression Settings.
Progressive vs baseline JPG
JPG ships in two scan orders, and progressive is the better choice for the web. The difference is how bytes are arranged, not how much detail is kept:
- Baseline encodes the image top-to-bottom; it renders row by row as bytes arrive.
- Progressive encodes coarse-to-fine; it shows a full blurry image first, then sharpens.
Progressive JPGs are typically 2–8% smaller than baseline at the same quality and feel faster to load. Most modern encoders, including MozJPEG, default to progressive. AVIF needs no such mode — its single decode pass already produces a complete image, which helps Core Web Vitals.
The migration story: keep masters, serve AVIF
Migrate by keeping JPG masters and serving AVIF with a JPG fallback. Do not discard the JPG; re-encoding a lossy JPG into lossy AVIF stacks two lossy passes, so encode AVIF from the highest-quality source you hold.
The standard delivery pattern uses the <picture> element:
<picture>
<source type="image/avif" srcset="/photo.avif" />
<img src="/photo.jpg" alt="…" width="1200" height="675" loading="lazy" decoding="async" />
</picture>
The browser picks AVIF when supported and falls back to JPG otherwise. To convert an existing JPG library to AVIF in the browser, use Convert JPG to AVIF; to produce a compatible JPG from an AVIF source, use Convert AVIF to JPG. The full delivery checklist lives in AVIF Optimization.
When JPG is still the right choice
JPG remains correct whenever maximum compatibility outranks file size. Four cases still call for JPG in 2026:
- Email attachments — many clients still render AVIF inconsistently.
- Ancient or locked-down clients — kiosk browsers and legacy enterprise builds.
- Re-encoding pipelines — social uploads transcode anyway, erasing the AVIF win.
- Universal downloadable bundles — press kits opened by unknown software.
For everything you control and deliver to modern browsers, AVIF is the stronger default. Compare the broader trade-offs in AVIF vs WebP, and choose a compression mode with Lossy vs Lossless Compression.
Frequently asked questions
Are JPG and JPEG the same format? Yes. The .jpg extension is a legacy three-character form of .jpeg, forced by old DOS filename limits. Both use the MIME type image/jpeg and are byte-identical.
Does converting JPG to AVIF lose quality? A small amount, because both are lossy. Encoding AVIF at quality 75–85 from a high-quality JPG stays visually indistinguishable while cutting size roughly in half.
Can AVIF fully replace JPG? Not yet for delivery to every device. AVIF reaches ~94% of users in 2026; ship it with a JPG fallback to cover the rest. See AVIF Browser Support.
Why does my JPG show blocky squares? Low quality factors zero out high-frequency DCT coefficients inside each 8×8 block, exposing the grid. Raise the quality factor or switch to AVIF, whose adaptive blocks avoid the artefact.
Sources and further reading
- JPEG standards committee — jpeg.org
- AVIF support tables — caniuse
- AVIF vs JPEG comparison — Uploadcare
- MozJPEG encoder — Mozilla
- AVIF format overview — the format that replaces JPG for delivery
- AVIF vs JPG — matched-quality comparison