1986: A committee, not a format
The history of JPEG doesn't begin with a file — it begins with a meeting. In 1986 the International Organization for Standardization (ISO), together with the International Telecommunication Union (ITU-T, back then still known as CCITT), founded a joint working group with a clear mandate: to standardize a lossy compression method for digital still images. The group carried the name that would later give the format its ring — the Joint Photographic Experts Group.
The name said it all. "Joint" stood for the collaboration between the two standards bodies; "Photographic" set the scope apart from graphics, diagrams or computer art; and "Experts Group" revealed that at first this wasn't about a product at all, but about a five-year research program. The first working drafts circulated in 1988, a first consensus standard was adopted in 1991, and on September 18, 1992 the final specification appeared as ISO/IEC 10918-1.
The idea: throw away what the eye doesn't see
JPEG's ingenious core idea is the Discrete Cosine Transform (DCT). The image is broken into 8×8-pixel blocks; each block is translated by the DCT from the pixel domain into the frequency domain. Low frequencies describe broad brightness and color gradients, high frequencies fine edges and noise. A subsequent quantization step throws away the high-frequency coefficients — the ones the human eye pays little attention to anyway. After that come the zigzag scan, run-length encoding and Huffman compression.
This pipeline was anything but obvious in the late 1980s. Competing proposals worked with block truncation, vector quantization or predictive methods. That DCT won came down to three factors: an outstanding quality-per-bit ratio, local processing without global memory, and hardware implementations that were feasible with the DSPs available at the time. A 386 could decode a JPEG — no fractal format could do that.
JFIF: how a standard became a file format
A frequently overlooked detail: ISO/IEC 10918-1 standardizes the compression algorithm, not the file format. What we know today as a "JPG file" is actually JFIF — the JPEG File Interchange Format, developed by Eric Hamilton at C-Cube Microsystems and published in 1992 as a de facto standard. JFIF defines how marker segments, quantization tables and image data are arranged in a byte sequence so that different decoders can read the same file.
In parallel, 1995 saw the emergence of Exif (Exchangeable Image File Format) from the Japanese JEIDA consortium, which extended JFIF with camera metadata: exposure time, aperture, GPS, camera model. Today almost every smartphone file is technically a JPEG data stream inside an Exif container — both standards live on side by side. You'll find a pragmatic explanation of this metadata in our post HEIC and HEIF explained, where we compare the successor-container logic.
1998–2004: the abandoned successors
Twice the committee tried to replace JPEG. JPEG 2000 (ISO/IEC 15444, ratified in December 2000) swapped the DCT for a wavelet transform and brought genuine advantages: lossless and lossy compression in the same algorithm, progressive resolution layers and markedly better compression efficiency. Even so, it never caught on the web. Three reasons: patent-encumbered implementations of several wavelet algorithms, encoders and decoders that were computationally expensive, and browser vendors who had no business interest in a new format as long as JPEG was "good enough." Today JPEG 2000 lives on in cinema projection (DCP), medical imaging (DICOM) and a handful of geographic information systems.
JPEG XR (originally Microsoft's HD Photo, standardized in 2009 as ISO/IEC 29199-2) met a similar fate. Microsoft built it into Windows Vista and the Internet Explorer family, but no other browser followed suit. Today it only holds a niche in Microsoft Office workflows.
Mozjpeg: a renaissance under an old specification
In 2014 Mozilla released Mozjpeg, a JPEG encoder that stays fully spec-compliant — every file can be opened with any old JPEG decoder — yet through clever encoder heuristics produces files 5–15% smaller than libjpeg-turbo. Three techniques make the difference: trellis quantization, optimized Huffman tables per image, and a smarter default quantization matrix. Mozjpeg proved that the format still had headroom even after more than two decades — without websites having to change a thing.
Mozjpeg is also the encoder that runs under our JPG compressor. Everything is processed entirely in the browser via WebAssembly — no upload, no account. For a technical deep dive on the encoder, see the JPG sweet-spot guide.
JPEG XL: the second serious attempt at a successor
In 2021 the ISO adopted JPEG XL (ISO/IEC 18181) as the latest iteration. Technically it's a complete redesign: better compression efficiency than AVIF, lossless re-compression of existing JPEGs (that is, 20% smaller files with no pixel loss), true HDR support and progressive loading. Browser adoption was hesitant at first — Chrome pulled an experimental implementation back out in 2022 — but in 2025 JPEG XL returned to Chrome and Edge, and Safari has supported it natively since macOS Sonoma. Whether it will prevail against AVIF and WebP is the open question of format politics in 2026. Our format comparison puts the three modern format options head to head.
Why JPEG still dominates after three decades
JPEG is one of the few formats in computing history to survive more than 30 years without a serious replacement. Three structural reasons:
- Universal support. Every device that displays digital images — from ATM screens and email clients to smartwatches — can decode JPEG. The format is the lingua franca of digital images.
- No patent risk. The original DCT patents expired in the mid-2000s. Unlike the long-running GIF/LZW dispute, there was never a serious commercial threat to free use. For the background, see our PNG-vs-WebP comparison, where we trace the format family tree.
- "Good enough" at the hardware level. Smartphone ISPs (Image Signal Processors) have cast dedicated JPEG encoders into silicon. Even if a new format were theoretically better, JPEG hardware acceleration is everywhere, and replacing it costs power and chip area.
Practical recommendations for 2026
For classic web photos, JPEG (rendered via Mozjpeg) remains the most robust choice. If you want maximum compression, serve WebP or AVIF alongside it and use the<picture> tag for progressive enhancement. In 2026 JPEG XL is still a bet — but for archives and photo backups, lossless JPEG re-compression offers a tangible byte saving. For UI elements, logos and diagrams, JPEG remains a poor choice: those belong in PNG, SVG or a WebP lossless variant — more on that in SVG vs. PNG vs. JPG for icons.
Anyone who wants to understand JPEG should see for themselves what quantization means: low quality settings produce visible block artifacts that have nothing in common with the mosaic effect of early internet streams except their cause. You'll find a demonstration of the typical failure patterns in the post JPEG artifacts.
Sources
ISO/IEC 10918-1 — JPEG specification · ITU-T Recommendation T.81 · Official page of the JPEG committee · Mozjpeg on GitHub · JPEG XL specification resources · ISO/IEC 15444-1 — JPEG 2000 · Eric Hamilton, "JPEG File Interchange Format," C-Cube Microsystems 1992.