Summary
In 1986, a working group of engineers from telecoms firms, camera makers, universities and broadcasters began meeting under a joint banner of the International Organization for Standardization and the CCITT — now the ITU-T — to answer a question that had no clean engineering answer. How much of a photograph could you throw away before a person noticed? Six years later, in September 1992, they published ITU-T Recommendation T.81, the specification the world now calls JPEG. It described a compression pipeline that routinely discards around 90 per cent of the data in a photograph and leaves the result looking, to most eyes, unchanged. That trade-off — invisible loss for enormous savings — is why the web looks the way it does. What the committee was actually arguing about The Joint Photographic Experts Group was formed in 1986 as a collaboration between ISO/IEC JTC 1 and what was then the CCITT. The problem in front of them was practical. Colour photographs, digitised at the resolutions people wanted for print and early desktop publishing, produced files far too large for the storage and modem speeds of the late 1980s. A single uncompressed 24-bit colour image at 640 by 480 pixels ran to about 900 kilobytes. On a 2,400-baud modem, that was roughly an hour to send one picture. Existing lossless techniques — run-length encoding, simple predictive coders — could shave perhaps a third off. Not nearly enough. The committee evaluated a dozen candidate methods across the late 1980s, including block truncation coding and vector quantisation, before settling on a discrete cosine transform pipeline broadly derived from work by Nasir Ahmed, T. Natarajan and K. R. Rao, whose 1974 paper in IEEE Transactions on Computers introduced the DCT as a practical image tool. The choice was not obvious at the time. What the DCT offered was a way to represent an image in a form where the information the human visual system barely uses could be identified and thrown out on purpose. How the pipeline throws data away A JPEG encoder does not compress a photograph by cleverly describing what is in it. It compresses by exploiting the specific weaknesses of human vision, which the committee spent years measuring and codifying into tables. The image is first converted from RGB into a colour space called YCbCr, which separates brightness (Y) from two colour-difference channels (Cb and Cr). Human eyes have far more receptors for luminance than for chrominance. The encoder takes advantage of this immediately by subsampling the colour channels, typically storing them at half resolution in each direction. That step alone discards three quarters of the colour information before any real compression has happened. Most viewers cannot see the difference. The image is then split into 8-by-8 pixel blocks. Each block runs through a two-dimensional discrete cosine transform, which rewrites those 64 pixel values as 64 coefficients describing how much of each spatial frequency the block contains — from the flat average (the DC term) up to fine, rapidly alternating patterns. Then comes the step where the loss actually lives. Each coefficient is divided by a value from a quantisation table and rounded to an integer. The tables in Annex K of T.81 are weighted so that high-frequency coefficients — the ones the eye is least sensitive to — are divided by much larger numbers, driving most of them to zero. A block that started as 64 numbers often ends as a handful of meaningful ones followed by a long run of zeros, which then compresses trivially with entropy coding (Huffman by default, or arithmetic coding, which the standard permits but which patent concerns kept out of common use for years). The quantisation tables are the heart of the standard. They are, in effect, a numerical description of how much visual information a human eye will tolerate losing at each spatial frequency. The committee’s suggested tables were derived from psychovisual experiments, and encoders scale them up or down to hit a target file size — the “quality” slider in every image editor is a multiplier applied to those tables. Where the 90 per cent figure comes from The often-quoted claim that JPEG discards around 90 per cent of the data refers to a typical mid-quality encode, roughly the default settings most software has shipped since the mid-1990s. A 24-bit photograph compressed at a quality factor around 75 to 85 usually lands at about a tenth of its uncompressed size, sometimes less. At quality 50, ratios of 20 to 1 are common. The exact number depends on the image; a photograph of foliage compresses less efficiently than a portrait against a plain background, because the leaves carry high-frequency detail the quantiser has to keep. What the committee could not measure precisely, and what the standard therefore does not describe, is where the threshold of visible loss actually sits for any given viewer, screen, or viewing distance. The tables were calibrated against averages. Any single reader, looking closely at a mid-quality JPEG, can find the blocky artefacts around sharp edges — the “mosquito noise” around text, the smeared colour along a bright red flower petal against a dark background. The standard is a bet on statistical inattention. What the standard does not do Two things about JPEG are widely misunderstood. The first: JPEG is a compression method, not a file format. What people call a “.jpg file” is almost always a JFIF or Exif container wrapping a JPEG bitstream. T.81 itself defines only the compressed data, not how to store metadata, thumbnails, colour profiles or orientation flags. That job was done by other specifications layered on top, which is why an image’s rotation can be wrong even when the pixels are fine — the Exif orientation tag and the actual pixel data are separate stories. The second: JPEG is not one algorithm. T.81 describes a baseline sequential mode, a progressive mode, a hierarchical mode, and a lossless mode that almost no one implemented. The web runs on baseline sequential and progressive. The lossless mode was later effectively replaced by JPEG-LS and then by other standards entirely. Why every photo on the web still looks like this Better compressors exist. JPEG 2000, finalised in 2000, uses wavelets instead of the DCT and produces smoother degradation at low bitrates. Google’s own comparison found WebP files averaging 25 to 34 per cent smaller than JPEG at equivalent visual quality, and AVIF and JPEG XL push the compression gains further still on top of that. None of them has displaced JPEG. The reason is inertia in the deepest sense. Every camera, every phone, every browser, every image library, every printer driver, every social platform’s upload pipeline, every CDN’s resizing service — all of them speak baseline JPEG. The format is unencumbered by active patent claims, cheap to decode on the smallest hardware, and produces files that any device made in the last thirty years can open. A newer format has to be better by a very large margin to overcome that. The consequence sits in the texture of the web itself. The soft edges around subtitles burned into a video thumbnail, the faint 8-by-8 grid visible in the sky of a heavily compressed travel photo, the way a screenshot of black text on white saved as JPEG looks slightly furry — all of it is the 1992 committee’s psychovisual bet, rendered billions of times a day. For more on how invisible standards shape what the network actually does, see how a DNS lookup climbs the root-server hierarchy before a browser can request a single JPEG, and how a submarine fibre thinner than a garden hose carries those bytes across oceans. JPEG XL was on track to become the successor for photographs; then Chrome pulled support in 2022, citing insufficient interest from the ecosystem. The decision drew years of pushback from developers and publishers, and in November 2025 Chrome’s own engineers said they would welcome a contribution to bring a memory-safe JPEG XL decoder back into the browser. A Rust-based decoder followed, shipping behind an experimental flag in Chrome 145 in February 2026. The committee has not stopped meeting. Whether JPEG XL or anything else eventually replaces baseline JPEG on the open web is still an open question.