The Committee That Built an Unkillable Format: JPEG's 36-Year Run

ToolHQ TeamAugust 1, 20266 min read

In 1986, a group of engineers from IBM, AT&T, and Canon sat down inside an ISO working group to solve a problem that had no clean solution: how do you store a photograph on a computer without using so much space that computers of the era simply couldn't cope?

Photography had always dealt in extremes. A professional color photo contained more tonal information than any digital medium of the 1980s could store affordably. Magnetic disks were expensive. Modems were slow. Transmission of uncompressed photographic images over telephone lines was measured not in seconds but in hours. The committee, formally called the Joint Photographic Experts Group, spent six years on that problem. The standard they published in September 1992 went on to become one of the most consequential pieces of software infrastructure in human history.

That standard is JPEG. And its core idea, the insight that made everything work, was that most of what your eye sees can be thrown away without you noticing.

The Mathematics of Acceptable Loss

The technical breakthrough at the heart of JPEG came not from the committee itself but from a 1974 paper by Nasir Ahmed, T. Natarajan, and K. R. Rao. Their work described something called the discrete cosine transform, a mathematical operation that converts spatial information (the arrangement of pixels in a grid) into frequency information (how rapidly those pixels change across a region). That paper was written years before the committee existed, but it was the most important citation in the eventual JPEG specification.

The insight is this: an 8-by-8 block of pixels contains both low-frequency information (smooth gradients, broad color fields) and high-frequency information (sharp edges, fine texture, rapid tonal transitions). Human vision processes these two types of information very differently. We are extraordinarily sensitive to low-frequency variation, we notice if a sky gradient is slightly off, or if a face's color temperature is wrong. We are far less sensitive to high-frequency detail, particularly in the color channels rather than the brightness channel.

JPEG's compression pipeline exploits this asymmetry deliberately. The image is first converted from RGB into a different color space, one that separates brightness from color, and the color channels are immediately sampled at half resolution, because the eye tolerates color imprecision far better than brightness imprecision. Then the image is divided into those 8-by-8 blocks, the DCT is applied to each one, and a quantization step discards the high-frequency data according to a table of perceptual tolerances. What is discarded at this step is gone permanently. There is no recovery. The final step applies lossless Huffman encoding to compress the remaining values further.

The JPEG specification's own authors noted that ten-to-one compression typically produces results indistinguishable from the original to the naked eye. That claim has been tested billions of times since 1992. It has largely held.

A Committee Standard That Became Unkillable

Part of what made JPEG so durable was the unusual process behind it. The GIF format, which preceded JPEG's mainstream adoption, was created essentially by one CompuServe engineer, Steve Wilhite. JPEG was the product of dozens of competing institutions spending years arguing about tradeoffs. IBM employees William B. Pennebaker and Joan L. Mitchell filed foundational patents on image compression techniques through the late 1980s as their contributions took shape. The final specification ran to over 600 pages.

That thoroughness created something that individual efforts tend not to produce: genuine robustness. JPEG was not built to impress a single company or satisfy a single use case. It was built to be defensible to experts from Canon to AT&T, from academic mathematicians to chip designers. The compression quality settings it exposed, the famous quality slider seen in every image editor, were the direct result of committee negotiation about what range of lossy behavior the standard had to accommodate.

The first application to implement JPEG compression was OS/2 Image Support, around 1990, two years before the standard was formally published. Nobody paid much attention. The moment JPEG actually became important to ordinary people was when Netscape Navigator, around 1995, marketed inline JPEG support as a feature. The web was still mostly GIF. Being able to display a compressed photograph in a browser window, without downloading a separate file, felt like sorcery. The adoption curve after that point was nearly vertical.

The Patents, the Challengers, and the Immovable Format

JPEG's success brought legal trouble. In the early 2000s, a company called Forgent Networks acquired patents from Compression Labs and claimed to own core elements of JPEG compression. Forgent extracted over a hundred million dollars from digital camera manufacturers before the patents were successfully challenged and ultimately expired around 2007. The episode was ugly, it echoed the GIF patent disputes that Unisys had run in the 1990s, but JPEG survived it without meaningful damage to its adoption.

What is remarkable is how many times better-designed successors have failed to displace it. JPEG 2000 arrived in 2000 with superior compression mathematics and lossless options. WebP launched in 2010 backed by Google, offering roughly thirty percent better compression than JPEG at equivalent quality. AVIF, based on the AV1 video codec, arrived in the late 2010s with compression gains that embarrassed every previous format. None of them have come close to ending the JPEG era.

The reason is not technical. Every engineer who has looked at the comparison charts knows that AVIF at a given file size produces a visibly better image than JPEG at the same size. The reason is infrastructure. Thirty years of cameras, phones, content management systems, social platforms, and image processing pipelines were built assuming JPEG. Every one of those systems represents a switching cost. The format is entrenched the way the QWERTY keyboard is entrenched, not because it is optimal, but because every alternative must overcome the weight of everything built on top of it.

What Compression Actually Destroys

The most widely misunderstood thing about JPEG compression is that its damage is not uniform. Smooth, low-frequency regions, clear sky, solid backgrounds, skin tones, compress beautifully. High-frequency regions, text on images, sharp edges between high-contrast colors, fine fabric texture, are where the quantization step causes visible artifacts. The characteristic JPEG defect, called blocking or ringing, appears as a faint 8-by-8 grid visible in smooth gradients at high compression, and as a slight halo around hard edges.

This is why applying JPEG compression to an already-compressed JPEG image compounds the damage asymmetrically. Each generation of compression goes through the quantization step again, and the blocking artifacts from the previous round become the high-frequency detail that the next round attacks. If you have ever seen a photograph that has been screenshotted and re-uploaded many times, you have seen this process at work.

Understanding this changes how you think about compression settings. For a landscape photograph with broad sky and gentle color gradients, a quality setting of 70 may produce a result visually identical to 95. For a photograph of printed text or a technical diagram, the same setting will introduce noticeable degradation. The right compression setting depends on what is in the image, not just the target file size.

Conclusion

Tools that compress images in the browser today apply the same DCT-based mathematics that the 1986 committee assembled. They expose simpler controls, a quality slider, a target file size, but the quantization tables underneath are direct descendants of Pennebaker and Mitchell's patent work. The committee built something that outlasted the technology they built it for, the legal challenges that threatened it, and every technically superior replacement that followed. That is a form of engineering success that does not show up in any benchmark.

If you have images that need to be smaller without visible loss, ToolHQ's Image Compressor applies browser-based compression with no upload required, the same DCT mathematics, no server.

Frequently Asked Questions

Why do JPEG images get worse each time they are saved?

Each save runs a new quantization step that permanently discards more high-frequency data. The artifacts from the previous save become the detail that the next save degrades, compounding the damage with every generation.

What types of images compress worst as JPEG?

Images with sharp edges, text, fine line patterns, or high-contrast transitions at small scales. These contain the high-frequency detail that JPEG's quantization step discards most aggressively.

Why hasn't WebP or AVIF replaced JPEG yet?

Decades of cameras, publishing platforms, and image pipelines were built assuming JPEG. Better compression mathematics cannot overcome the switching cost embedded in that infrastructure.

What is the discrete cosine transform?

A mathematical operation that converts pixel data from a spatial grid into frequency components, allowing JPEG to identify and discard the high-frequency detail that the human eye is least sensitive to.

Try These Free Tools