1986: Ein Komitee, kein Format

Die Geschichte von JPEG beginnt nicht mit einer Datei, sondern mit einer Sitzung. 1986 gründete die International Organization for Standardization (ISO) gemeinsam mit der International Telecommunication Union (ITU-T, damals noch CCITT) eine gemeinsame Arbeitsgruppe mit einem klaren Auftrag: ein verlustbehaftetes Komprimierungsverfahren für digitale Standbilder zu standardisieren. Die Gruppe trug den Namen, der dem Format später seinen Klang gab — die Joint Photographic Experts Group.

Der Name war Programm. „Joint" stand für die Zusammenarbeit der beiden Standards-Organe; „Photographic" grenzte den Anwendungsbereich gegen Grafiken, Schemata oder Computer-Art ab; „Experts Group" verriet, dass es zunächst nicht um ein Produkt ging, sondern um ein fünfjähriges Forschungsprogramm. Die ersten Working-Drafts zirkulierten 1988, ein erster Konsens-Standard wurde 1991 verabschiedet, und am 18. September 1992 erschien die finale Spezifikation als ISO/IEC 10918-1.

Die Idee: Wegwerfen, was das Auge nicht sieht

Der genialer Kerngedanke von JPEG ist die Diskrete Kosinus-Transformation (DCT). Das Bild wird in 8×8-Pixel-Blöcke zerlegt; jeder Block wird per DCT vom Pixel-Raum in den Frequenz-Raum übersetzt. Niedrige Frequenzen beschreiben großflächige Helligkeits- und Farbverläufe, hohe Frequenzen feine Kanten und Rauschen. Eine anschließende Quantisierung wirft die hochfrequenten Koeffizienten weg, denen das menschliche Auge ohnehin wenig Aufmerksamkeit schenkt. Anschließend folgen Zickzack-Scan, Lauflängen-Kodierung und Huffman-Kompression.

Diese Pipeline war in den späten 80ern nicht selbstverständlich. Die Konkurrenz-Vorschläge arbeiteten mit Block-Truncation, Vektor-Quantisierung oder prädiktiven Verfahren. Dass DCT gewann, lag an drei Faktoren: hervorragende Qualität-pro-Bit-Ratio, lokale Verarbeitung ohne globalen Speicher und Hardware-Implementierungen, die mit den damals verfügbaren DSPs realisierbar waren. Ein 386er konnte ein JPEG dekodieren — kein fraktales Format konnte das.

JFIF: Wie aus einem Standard ein Dateiformat wurde

Ein häufig übersehenes Detail: ISO/IEC 10918-1 standardisiert denKomprimierungs-Algorithmus, nicht das Dateiformat. Was wir heute als „JPG-Datei" kennen, ist eigentlich JFIF — das JPEG File Interchange Format, entwickelt von Eric Hamilton bei C-Cube Microsystems und 1992 als De-facto-Standard veröffentlicht. JFIF definiert, wie Marker-Segmente, Quantisierungs-Tabellen und Bilddaten in einer Bytefolge angeordnet werden, damit verschiedene Decoder dieselbe Datei lesen können.

Parallel entstand 1995 Exif (Exchangeable Image File Format) durch das japanische JEIDA-Konsortium, das JFIF um Kamera-Metadaten erweiterte: Belichtungszeit, Blende, GPS, Kameramodell. Heute ist fast jede Smartphone-Datei technisch ein JPEG-Datenstrom in einem Exif-Container — beide Standards existieren parallel weiter. Eine pragmatische Erklärung dieser Metadaten findest du in unserem Beitrag HEIC und HEIF erklärt, in dem wir die Nachfolge-Container-Logik vergleichen.

1998–2004: Die abgebrochenen Nachfolger

Zweimal versuchte das Komitee, JPEG abzulösen. JPEG 2000 (ISO/IEC 15444, ratifiziert im Dezember 2000) ersetzte die DCT durch eine Wavelet-Transformation und brachte echte Vorteile mit: verlustfreie und verlustbehaftete Komprimierung im selben Algorithmus, sukzessive Auflösungs-Layer und eine deutlich bessere Komprimierungs-Effizienz. Trotzdem setzte es sich nie im Web durch. Drei Gründe: patentbelastete Implementierungen mehrerer Wavelet-Algorithmen, Encoder/Decoder waren rechenintensiv und Browser-Hersteller hatten kein Geschäfts-Interesse an einem neuen Format, solange JPEG „gut genug" war. Heute lebt JPEG 2000 in Kino-Projektion (DCP), medizinischer Bildgebung (DICOM) und einigen Geo-Informations-Systemen weiter.

JPEG XR (ursprünglich Microsofts HD Photo, 2009 als ISO/IEC 29199-2 standardisiert) hatte ein ähnliches Schicksal. Microsoft brachte es in Windows Vista und die Internet-Explorer-Familie ein, aber kein anderer Browser zog mit. Aktuell hat es nur noch in Microsoft-Office-Workflows eine Nische.

Mozjpeg: Eine Renaissance unter alter Spezifikation

2014 veröffentlichte Mozilla Mozjpeg, einen JPEG-Encoder, der vollständig spezifikations-konform bleibt — jede Datei lässt sich mit jedem alten JPEG-Decoder öffnen — aber durch raffinierte Encoder-Heuristiken 5–15 % kleinere Dateien produziert als libjpeg-turbo. Drei Techniken machen den Unterschied: Trellis-Quantisierung, optimierte Huffman-Tabellen pro Bild und eine intelligentere Standard-Quantisierungs-Matrix. Mozjpeg bewies, dass das Format selbst nach über zwei Jahrzehnten noch Reserven hatte — ohne dass Webseiten umgestellt werden mussten.

Mozjpeg ist auch der Encoder, der unter unserem JPG-Komprimierer läuft. Die Verarbeitung passiert komplett im Browser via WebAssembly — kein Upload, kein Account. Eine technische Tiefe zum Encoder findest du im JPG-Sweet-Spot-Leitfaden.

JPEG XL: Der zweite ernsthafte Nachfolge-Versuch

2021 verabschiedete die ISO JPEG XL (ISO/IEC 18181) als jüngste Iteration. Technisch ist es eine vollständige Neuentwicklung: bessere Komprimierungseffizienz als AVIF, verlustfreie Re-Komprimierung existierender JPEGs (also 20 % kleinere Dateien ohne Pixelverlust), echte HDR-Unterstützung und progressives Laden. Browser-Adoption war zunächst zögerlich — Chrome zog 2022 eine experimentelle Implementierung wieder zurück — aber 2025 kehrte JPEG XL in Chrome und Edge zurück, und Safari unterstützt es nativ seit macOS Sonoma. Ob es sich gegen AVIF und WebP durchsetzt, ist die offene Frage der Format-Politik 2026. Eine direkte Gegenüberstellung der drei modernen Format-Optionen liefert unser Formate-Vergleich.

Warum JPEG nach über drei Jahrzehnten dominiert

JPEG ist eines der wenigen Formate, die in der Computer-Geschichte mehr als 30 Jahre ohne ernsthafte Ablösung überlebt haben. Drei strukturelle Gründe:

  • Universelle Unterstützung. Jedes Gerät, das digitale Bilder anzeigt — vom Geldautomaten-Display über E-Mail-Clients bis zur Smartwatch — kann JPEG dekodieren. Das Format ist die Lingua franca digitaler Bilder.
  • Kein Patent-Risiko. Die ursprünglichen DCT-Patente liefen Mitte der 2000er aus. Anders als beim langen GIF/LZW-Streit gab es nie eine ernsthafte kommerzielle Bedrohung der freien Nutzung. Für die Hintergründe siehe unseren PNG-vs.-WebP-Vergleich, in dem wir den Format-Stammbaum aufrollen.
  • „Good enough" auf Hardware-Niveau. Smartphone-ISPs (Image Signal Processors) haben dedizierte JPEG-Encoder in Silizium gegossen. Selbst wenn ein neues Format theoretisch besser wäre — die JPEG-Hardware-Beschleunigung ist überall, und das Ablösen kostet Strom und Chip-Fläche.

Praktische Empfehlungen für 2026

Für klassische Web-Fotos bleibt JPEG (gerendert über Mozjpeg) die robusteste Wahl. Wer maximale Komprimierung will, liefert parallel WebP oder AVIF aus und nutzt den<picture>-Tag für progressive Enhancement. JPEG XL ist 2026 noch ein Wett-Spiel — aber für Archive und Foto-Backups bietet die verlustfreie JPEG-Re-Komprimierung eine handfeste Bytes-Ersparnis. Für UI-Elemente, Logos, Diagramme bleibt JPEG eine schlechte Wahl: hier gehört PNG, SVG oder eine WebP-Lossless-Variante hin — mehr dazu in SVG vs. PNG vs. JPG für Icons.

Wer JPEG verstehen will, sollte einmal mit eigenen Augen sehen, was Quantisierung bedeutet: niedrige Qualitätswerte produzieren sichtbare Block-Artefakte, die mit dem Mosaik-Effekt früher Internet-Streams nichts gemein haben außer der Ursache. Eine Demonstration der typischen Fehlerbilder findest du im Beitrag JPEG-Artefakte.

Quellen

ISO/IEC 10918-1 — JPEG-Spezifikation · ITU-T Recommendation T.81 · Offizielle Seite des JPEG-Komitees · Mozjpeg auf GitHub · JPEG-XL-Spezifikationsressourcen · ISO/IEC 15444-1 — JPEG 2000 · Eric Hamilton, „JPEG File Interchange Format", C-Cube Microsystems 1992.