The JPEG Turns 34: A Complete History of the Web's Most Famous Image Format

On September 18, 1992, ISO published a 186-page document titled ISO/IEC 10918-1 — a specification for compressing photographs into small, shareable files. Thirty-four years later, that document is still the reason your phone, your camera, your inbox, and almost every image you've ever seen online exists in the format it does. A dozen would-be successors have come and gone. The JPEG is still everywhere. Here's how it got there — and why it's still winning.

This isn't a technical paper. It's a deep dive into the actual history — the people, the math, the format wars, the dumbest naming controversy in computing, and the political knife fight that's been quietly shaping image formats since 2022. By the end you'll understand why a format designed for 56k modems is somehow still the default in 2026.

Was JPEG the First Image Format?

No. And the formats that came before it shaped what JPEG had to be.

By the late 1980s, a handful of digital image formats already existed:

• BMP (Microsoft, 1985) — stored pixel data uncompressed. A 640x480 photo took up almost a megabyte. Universal but enormous.
• TIFF (Aldus, 1986) — designed for desktop publishing. Flexible, supported lossless compression (LZW), but the spec was so permissive that no two TIFF readers handled the same file the same way.
• GIF (CompuServe, 1987) — the format of the early online era. Files were small, browsers loved them, dial-up bulletin boards could host them. But GIF was capped at 256 colors total. That worked for line art and logos. For photographs, it was a catastrophe.
• PCX (1985) — PC Paintbrush's native format. Run-length encoding gave it some compression, but it was tied to a single program's paradigm and never really left the IBM-PC world.

None of these solved the actual problem photographers and publishers were facing: how do you store full-color photographs — millions of colors, continuous tones, smooth gradients — in a file small enough to fit on a floppy disk or transmit over a 9600-baud modem?

The answer wasn't a better implementation of an existing approach. It was a fundamentally new kind of compression — built on math nobody outside academia had ever heard of.

The Math That Made JPEG Possible (1972)

In 1972, an electrical engineering professor at Kansas State University named Nasir Ahmed had an idea that would quietly become one of the most economically important inventions of the late 20th century.

Ahmed was studying signal processing — the math behind compressing audio, video, and images — when he proposed a transform he called the Discrete Cosine Transform (DCT). The idea was simple to state and devastatingly effective in practice: any chunk of an image (or any signal, really) can be represented as a sum of cosine waves at different frequencies. Smooth, gradient-y parts of an image are dominated by low-frequency components. Sharp edges and fine detail show up as high-frequency components.

Ahmed's insight was that human vision is much more sensitive to low-frequency information than high-frequency information. If you discard a chunk of the high-frequency data — or quantize it down to fewer possible values — most people can't tell the difference. But the file size drops by an order of magnitude.

Ahmed worked with two collaborators — T. Natarajan and K. R. Rao — to formalize the math. Their 1974 paper, "Discrete Cosine Transform" in IEEE Transactions on Computers, introduced what would become the foundational compression algorithm of modern media. Twenty years later, DCT would be powering JPEG, MP3, MPEG video, H.264, and effectively every lossy media compression standard on Earth.

Ahmed himself didn't get rich off it. He proposed the math, published the paper, kept teaching, eventually moved to the University of New Mexico, and watched his obscure transform quietly become the engine of the global compression industry. Most people who use it every day have never heard his name.

The Joint Photographic Experts Group (1986)

In 1986, two of the world's largest standards bodies — the International Organization for Standardization (ISO/IEC) and what was then called the CCITT (now ITU-T) — formed a joint committee with a single mission: produce an international standard for compressing continuous-tone still images.

That committee was called the Joint Photographic Experts Group. JPEG isn't a file format — it's a committee. The format is named after the group that created it. When you say "JPEG file," you're really saying "Joint Photographic Experts Group file."

The committee pulled in researchers from across the industry: IBM, AT&T, Bell Labs, KDD, ENEA, Hewlett-Packard, the British Telecom research labs, and — critically — a small Silicon Valley company called C-Cube Microsystems that was building dedicated DCT compression chips.

Two IBM researchers in particular — William B. Pennebaker and Joan L. Mitchell — became the public faces of the standard. Their 1993 textbook, JPEG: Still Image Data Compression Standard, is still considered the canonical reference. Mitchell later became the first woman elected president of the IBM Academy of Technology. Pennebaker holds dozens of compression patents. Together they spent six years hammering out a standard the entire imaging industry could agree on.

Six years is a long time. By the time the JPEG committee was done, the World Wide Web was about to launch — and the format they shipped landed at exactly the right moment.

The 1992 Standard (ISO/IEC 10918-1)

The first JPEG standard — formally ISO/IEC 10918-1, also known as ITU-T Recommendation T.81 — was published in September 1992.

It defined four distinct compression modes:

• Baseline sequential — what most people think of as "JPEG." Lossy, DCT-based, 8 bits per channel, encoded one block at a time from top-left to bottom-right.
• Extended sequential — same approach, but with optional 12-bit precision and arithmetic coding.
• Progressive — encodes the whole image in passes, low-frequency to high-frequency. As the file downloads, the image resolves from blurry to sharp.
• Hierarchical — encodes the image at multiple resolutions, useful for thumbnails and progressive previews.

The standard also included a lossless mode — yes, JPEG technically supports lossless compression — which used a completely different algorithm (predictive coding) and was almost never adopted in practice.

Part 1 of the standard defined the compression. Parts 2 through 5, published over the following years, added compliance testing, technical extensions, registration authorities, and a reference implementation. Part 1 is the part that mattered.

What ISO/IEC 10918-1 did not define was the actual file format. The standard described how to compress an image and how to encode the resulting bitstream. It said nothing about how to wrap that bitstream in a file you could save to disk and email to your aunt. For that, you needed JFIF.

JFIF — The File Format That's Actually on Your Hard Drive

In 1992, the same year ISO published the JPEG standard, Eric Hamilton at C-Cube Microsystems quietly published a separate spec called JFIF — the JPEG File Interchange Format.

JFIF defined the file structure: how to wrap a JPEG-compressed bitstream in a file with the right markers, segments, and metadata so that any program could open it and know what to do.

Every JFIF file starts with a two-byte Start Of Image marker (0xFFD8), followed by application segments, quantization tables, Huffman tables, the actual compressed image data, and a closing End Of Image marker (0xFFD9). It's elegant, predictable, and trivially easy to parse — which is exactly why every imaging library on Earth supports it.

When you save a "JPEG" today, what you're actually saving is JFIF wrapping a JPEG-compressed bitstream. The two were so commonly bundled together that JFIF effectively became the "real" JPEG file format, even though the underlying compression and the file structure are technically separate specifications.

A few years later, in 1995, the Japan Electronic Industries Development Association (JEIDA) added another layer: EXIF — the Exchangeable Image File Format. EXIF embeds camera metadata directly into JPEG files: shutter speed, ISO, GPS coordinates, camera model, lens, timestamp, even thumbnail previews. Modern JPEGs are usually JFIF + EXIF + the JPEG-compressed bitstream, all stacked into a single file.

EXIF is also the reason every photo from your phone has GPS coordinates baked into it — which is great for your photo library and terrifying if you've ever uploaded a vacation photo without scrubbing the metadata first. (Quick plug: our Metadata Remover app strips that data offline before you share.)

JPG vs JPEG — The Dumbest Naming Controversy in Tech

Here's the question I've been asked more times than any other on this subject: what's the difference between JPG and JPEG?

The answer: nothing. They're the same file.

The reason both extensions exist comes down to one of the dumbest constraints in computing history — the 8.3 filename limit from the old DOS and Windows 95 FAT16 filesystem. On those systems, every filename had to fit into 8 characters for the name plus 3 characters for the extension. That's why early-90s files all looked like RESUME.DOC and IMAGE001.BMP.

When JPEG files arrived, "JPEG" was four characters. Too long. So Windows and DOS used .jpg instead — chopping the "E" off to fit the 8.3 rule.

Mac OS, Unix, and Linux had no such limit. They used .jpeg.

The format itself is identical. There's no compression difference, no metadata difference, no quality difference. Whether a file ends in .jpg or .jpeg, it's the same bytes encoded the same way. Most browsers, image viewers, and operating systems treat them interchangeably.

Today, .jpg is the more common extension because Windows dominated personal computing through the '90s and '00s and the convention stuck. But .jpeg is technically the original and arguably the "correct" one — it matches the actual name of the format.

If you're choosing for a new project? It honestly doesn't matter. Pick one and be consistent. Most people use .jpg.

Why JPEG Won the 1990s Format War

Once JPEG and JFIF were public in 1992, the format hit a remarkable confluence of timing and execution.

1993: NCSA Mosaic — the first widely-used graphical web browser — launched with native support for JPEG, GIF, and XBM. Suddenly there was a market for inline web images.

1994: Netscape 1.0 shipped. The web exploded. JPEG was the only practical format for photographs.

1995: Internet Explorer 1.0 launched. Same JPEG support.

By 1996, JPEG was already the de facto photographic format of the web. The reasons it won were straightforward:

• vs GIF: 16.7 million colors vs 256. For photographs, this was no contest.
• vs TIFF: TIFF was technically superior in many ways — but a 5MB lossless TIFF was useless on a 14.4k modem.
• vs BMP: BMP didn't compress at all. Game over.
• vs PNG (1996): PNG won lossless transparency and indexed graphics, but couldn't touch JPEG for photos. The two formats settled into complementary roles.

The combination of "small enough for the modem internet" plus "good enough that nobody could see the artifacts" plus "open standard with no licensing fees" was unbeatable. Camera manufacturers adopted JPEG as the native format for digital cameras in the late '90s. Phone cameras followed in the 2000s. By the time the iPhone launched in 2007, JPEG was already ambient infrastructure — invisible, ubiquitous, taken for granted.

Progressive JPEG and the Dial-Up Era

If you used the internet in the late 1990s, you remember progressive JPEGs — even if you didn't know what they were called.

A baseline JPEG downloads top-to-bottom, like a printer. You'd watch the top of the image appear first, then the middle, then the bottom — in horizontal stripes. On a 28.8k modem, this could take 30 seconds for a single image.

A progressive JPEG encodes the same image in multiple passes — low-frequency information first, then progressively higher-frequency detail. As the file downloads, the entire image appears immediately, but blurry, and gets sharper as more data arrives. Visually, it's a dramatic improvement: you see the whole picture instantly, even if the detail takes a few seconds to fill in.

Progressive JPEGs were a small detail that made the early web feel meaningfully faster. The feature still ships with every JPEG encoder today. On modern broadband, the difference is unnoticeable. On a slow mobile connection or a cheap rural ISP, progressive encoding still earns its keep.

JPEG Features You Probably Didn't Know Existed

The JPEG standard is way deeper than "compress an image." Most of it never got widely used.

Restart markers — JPEG can be encoded with periodic synchronization points so that if part of the file gets corrupted, the rest of it can still be recovered. This was crucial for transmitting JPEGs over noisy radio links and unreliable network connections in the 1990s. Modern files almost never use them.

ICC color profiles — JPEGs can embed full color management profiles describing exactly what color space the file uses (sRGB, Adobe RGB, ProPhoto, etc.). Most browsers ignore them. Photo editors use them religiously.

12-bit precision — The standard supports 12 bits per channel for higher dynamic range. Almost nobody ships 12-bit JPEGs because almost nothing reads them.

Lossless JPEG mode — A completely different compression algorithm bundled into the same standard. Used in some medical imaging, basically nowhere else.

Arithmetic coding — A more efficient entropy coder than the Huffman coding JPEG uses. Would have shrunk JPEGs by another 5–10%. Killed by patent licensing concerns at IBM, AT&T, and Mitsubishi. Even after the patents expired in 2007, no major encoder enabled it by default — too risky to break compatibility with twenty years of installed JPEG decoders.

The things JPEG could have been — but isn't — are almost as interesting as the things it actually is.

The First Failed Successor: JPEG 2000 (2000)

By the late 1990s, the JPEG committee was already working on a replacement.

JPEG 2000 — formally ISO/IEC 15444 — was published in December 2000. Instead of DCT, it used wavelet transforms — a mathematically newer compression approach that delivered dramatically better quality at low bit rates.

JPEG 2000 was, on paper, a massive upgrade:

• 25–35% smaller files at equivalent quality
• Excellent quality at extreme compression (down to 0.1 bits per pixel)
• Lossy and lossless compression in a single file
• Region-of-interest encoding (encode parts of the image at higher quality)
• Better resilience to file corruption

It also failed almost completely in the consumer market.

The reasons were boring and decisive: the wavelet algorithms were patent-encumbered, browser vendors didn't want to ship a decoder, and end users didn't have a reason to care. The original JPEG was already "good enough." The switching cost — encoding everything twice, dealing with browser support nightmares, training every imaging tool to handle a new format — was massive. The benefit, for the average person looking at family photos, was nearly invisible.

Today JPEG 2000 lives on in two niches:

• Digital cinema — DCP (Digital Cinema Package) files use JPEG 2000 for distribution to movie theaters. Every modern film you've seen in a theater is shipped on a hard drive full of JPEG 2000 frames.
• Medical imaging — Some DICOM medical scan formats use JPEG 2000 for its lossless compression and region-of-interest encoding.

Outside those two domains, JPEG 2000 is dead. It was a brilliant standard that solved a problem nobody had urgently enough to switch.

The Second Failed Successor: JPEG XR (2009)

A decade after JPEG 2000 flopped, the JPEG committee tried again.

JPEG XR — formally ISO/IEC 29199 — was originally a Microsoft creation called Windows Media Photo (later rebranded to HD Photo). Microsoft handed it to the JPEG committee and it was standardized as JPEG XR in 2009.

JPEG XR delivered better compression than baseline JPEG, native HDR support (16–32 bits per channel), lossless and near-lossless modes, and tiled encoding for fast random access.

It also failed, for the same reason JPEG 2000 failed: nobody outside the originating company cared. Internet Explorer added support. No other browser did. Photographers had no reason to switch from JPEG. Cameras kept shipping JPEG. The format quietly disappeared from public conversation by 2015.

The JPEG committee was now 0-for-2 on successor formats. The actual challenge to JPEG's dominance wouldn't come from the JPEG committee at all — it would come from outsiders.

The 2010s Modern Challenger Lineup

By the early 2010s, web giants had decided that incremental gains over JPEG mattered enough to fund their own format development.

WebP (Google, 2010) was the first serious challenger. Built on the VP8 video codec, WebP delivered 25–35% smaller files than JPEG at equivalent quality, plus alpha transparency and animation. Chrome supported it from day one. Firefox dragged its feet for nine years before adding support in 2019. By 2021, WebP had near-universal browser support.

HEIC / HEIF (Apple, 2017) is the format every iPhone has been shooting since iOS 11. Built on the HEVC (H.265) video codec, HEIC stores about half the file size of JPEG at equivalent quality, with full HDR support. The catch: HEVC is patent-encumbered, which means HEIC is essentially walled into the Apple ecosystem. Web browsers don't support it. Most non-Apple software needs a paid decoder. It works beautifully on iPhones and is a nightmare anywhere else.

AVIF (AOMedia, 2019) is the heir apparent. Built on the royalty-free AV1 video codec, AVIF delivers 30–50% smaller files than WebP and up to 80% smaller than JPEG at equivalent quality. Browser support landed in Chrome (2020), Firefox (2021), and Safari (2022). Today, AVIF is the format any serious web developer should be using for photographic content.

For a deeper breakdown of how these modern formats actually work — and how to convert your images — see our guide to compressing images without losing quality.

But there was one more JPEG successor worth talking about — and its story is the wildest of the bunch.

The JPEG XL Drama (2021–2026)

In 2021, the JPEG committee finalized JPEG XL — formally ISO/IEC 18181 — as a third attempt at a JPEG successor.

JPEG XL was different from its predecessors. It had a killer feature nobody else offered: lossless transcoding from existing JPEGs. You could convert your entire JPEG library to JPEG XL — getting roughly 20% smaller files for free — and convert back to bit-identical original JPEGs whenever you wanted. The migration story was effortless. No quality loss. No re-encoding artifacts. No "do I really want to commit to this?" anxiety.

Beyond that, JPEG XL was technically excellent. Better compression than AVIF in many cases, better progressive decoding, lossless and lossy in the same format, animation support, CMYK and HDR support, and a royalty-free patent license.

The format community was elated. JPEG XL felt like the genuine, no-strings replacement for JPEG that the standard had been searching for since 2000.

Then Google killed it.

In October 2022, the Chrome team announced they would remove JPEG XL support from Chromium without ever shipping it by default. The official reason: "not enough interest from the ecosystem." The unofficial reason — widely believed in the developer community — was that Google wanted to push AVIF, which is built on Google's own AV1 codec.

Mozilla declined to ship JPEG XL in Firefox without a clearer adoption path. Chrome's removal in Chrome 110 (February 2023) effectively killed the format's web prospects. Apple, contrarian as ever, shipped JPEG XL natively in Safari 17 (September 2023).

"The technically best format does not win. The format that ships in Chrome wins."

The developer community revolted. Adobe added JPEG XL support to Lightroom and Photoshop. Meta filed comments asking Google to reconsider. The Internet Archive backed JPEG XL. A petition signed by more than a thousand developers asked Chrome to reverse course.

As of early 2026, JPEG XL is in a weird limbo: it ships natively in Apple Safari, sits behind opt-in flags in Chromium and Firefox, and has zero meaningful adoption on the open web. The technical case for it remains strong. The political case — at least at Google's scale — has been lost. Most developers have moved on to AVIF.

It's a good cautionary tale about how internet standards actually get adopted. A standard's quality is not what determines its fate. Distribution is.

Why JPEG Still Wins in 2026

After 34 years, six successor formats, and three coordinated efforts to replace it, JPEG is still everywhere. Why?

Universal compatibility. Every device, every browser, every camera, every email client, every messaging app, every social media platform, every operating system back to Windows 95 supports JPEG. There is no other image format that comes close to that ubiquity. That's a 30-year network effect that no challenger has been able to overcome.

No licensing drama. JPEG is patent-free. There are no royalties to pay, no licenses to negotiate, no sudden surprises when a major company decides to enforce a hidden patent claim. Every other modern format has at least some licensing complexity baked into its lineage.

"Good enough" compression. Yes, AVIF makes 50% smaller files. But the average user looking at a Facebook photo on their phone cannot tell the difference between a 200KB JPEG and a 100KB AVIF. The difference matters at scale — to Facebook's CDN bills, to Netflix's bandwidth, to Lighthouse scores — but not to humans looking at photos.

Trivial encoding cost. A microcontroller in a $10 doorbell camera can encode JPEGs all day. AVIF and HEIC require dramatically more CPU. JPEG runs on basically anything.

Ambient infrastructure. Every digital camera in the world ships shooting JPEG by default. Every photo library on Earth is full of JPEGs. Every backup, every archive, every image hosting service — JPEG. The switching cost is the entire ecosystem.

The new formats are objectively better. JPEG is irreplaceable.

Should You Still Ship JPEGs in 2026?

Yes. But not exclusively.

For modern web pages where Core Web Vitals matter — and they do, because Google ranks based on them — your primary format should be AVIF or WebP, with JPEG as a fallback. The idiomatic way to do this is the <picture> element:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image">
</picture>

Every modern browser will pick the best format it supports. Older browsers fall through to the JPEG. Your file size drops by 30–50%, your LCP improves, your search rankings benefit. (For more on how invalid HTML and missing image attributes hurt rankings, see our deep dive on HTML validation and SEO.)

For everything else — email, embedded systems, archive storage, user uploads, anything that needs maximum compatibility — JPEG is still the right answer. It always will be.

If you've got a backlog of JPEGs that need to be modernized for the web, the fastest way to bulk-convert is with Batch WebP Converter or Batch AVIF Converter — both Windows desktop apps that run completely offline and process entire folders in one shot. No uploads, no daily caps, no watermarks.

Drop a project folder in, get back optimized WebP or AVIF in minutes. The AVIF version includes a TURBO mode for maximum compression, and the WebP version has the broadest browser compatibility for legacy fallback. Pair them with the JPEG library you already have and you've got the full picture.

Bottom Line — The Duct Tape of the Internet

The JPEG turned 34 this year. It is older than most of the engineers who ship it. It has been pronounced obsolete at least four times. It has watched JPEG 2000, JPEG XR, WebP, HEIC, AVIF, and JPEG XL all stake claims on its throne. And it is still, in 2026, the most common image format on Earth.

It is the duct tape of the internet — not the prettiest, not the most efficient, but the one thing that holds everything together. It is the photo format on your phone, the attachment format in your email, the export option in your camera, the fallback format in your <picture> element, and the format embedded in every PDF, every Word document, and every printed photo album in the world.

The successors will keep coming. AVIF will keep gaining ground. JPEG XL might come back from the dead someday. New formats will be standardized, debated, and celebrated. And quietly, in the background, JPEG will keep doing what it has done for thirty-four years: showing up everywhere, asking for nothing, and refusing to die.

Happy birthday, JPEG. You earned it.

Sources: web.dev — Use WebP images, web.dev — Use AVIF for compressed images, JPEG.org — Official JPEG committee site, ITU-T Recommendation T.81 (the JPEG standard), ISO/IEC 10918-1:1994, Discrete Cosine Transform — Wikipedia, Nasir Ahmed — Wikipedia, Pennebaker & Mitchell, JPEG: Still Image Data Compression Standard (Van Nostrand Reinhold, 1993). JPEG XL standardization and Chrome timeline reconstructed from public Chromium issue tracker discussions and the JPEG XL working group meeting notes.