Bildformate fürs Web 2026 wählen: JPEGs Imperium, AVIFs Aufstieg und JPEG XLs Exil

Nimm ein 12-MP-Foto (4000 × 3000 Pixel) und exportiere es auf sechs Arten. PNG: 24 MB. JPEG in Qualität 90: 3,4 MB. WebP bei vergleichbarer Bildqualität: etwa 2,4 MB. AVIF bei vergleichbarer Bildqualität: etwa 1,7 MB. GIF, auf sein 256-Farben-Limit heruntergedithert: 6 MB, mit sichtbarem Banding überall. SVG taucht in der Liste gar nicht auf: Es beschreibt Zeichnungen, und ein Foto ist keine.

Dasselbe Bild auf dem Bildschirm, ein Faktor 14 auf der Festplatte. Dieser Unterschied ist Ingenieursarbeit, keine Geschmacksfrage. Jedes Format ist ein Bündel von Entscheidungen, getroffen unter den Zwängen eines bestimmten Jahres – und diese Entscheidungen tauchen noch heute in deinem Page Weight auf.

Das hier ist die Entscheidungsversion dieses Experiments: was jedes Format tatsächlich mit deinen Pixeln anstellt, welche Browser es Mitte 2026 dekodieren, was das Web wirklich ausliefert – und am Ende eine Tabelle, die du in ein Team-Wiki kopieren kannst.

Die Kandidaten, einer nach dem anderen

JPEG (1992). Der Mechanismus: Das Bild wird in 8 × 8-Blöcke zerlegt, jeder Block per diskreter Kosinustransformation in Frequenzen überführt, dann werden die feinen Details anhand eines Modells des menschlichen Sehens gegen null quantisiert. Stärken: dekodiert auf jedem Gerät seit Mitte der 90er, kodiert schnell und ist hervorragend bei Fotos mit kontinuierlichen Tonwerten. Schwächen: keine Transparenz, keine Animation, sichtbares Ringing um scharfe Kanten und Text, und eine Qualität, die mit jedem erneuten Speichern weiter sinkt. Passt zu Fotos und zu allem, was absolut überall aufgehen muss.

PNG (1996). Der Mechanismus: vollständig verlustfrei. Jede Bildzeile wird mit einem Prädiktor gefiltert und dann mit DEFLATE gepackt, derselben Kombination aus LZ77 und Huffman wie in gzip. Stärken: Pixel-exakte Ausgabe, voller Alphakanal, universeller Support. Die Schwäche sind Fotos: Sensorrauschen macht den Prädiktor zunichte, ein 12-MP-Foto komprimiert vielleicht 1,5:1 gegenüber den Rohpixeln. Passt zu Screenshots, UI-Aufnahmen, Diagrammen und allem mit Text oder flächiger Farbe.

GIF (1987). Der Mechanismus: LZW-Komprimierung über einer Palette von höchstens 256 Farben, mit mehreren Frames in einer Datei. Die einzige verbliebene Stärke ist Animation, die überall läuft, auch in E-Mail-Clients ohne Unterstützung für moderne Formate. Der Rest ist Schwäche: 256 Farben, Ein-Bit-Transparenz und Dateien, die das äquivalente Video um Längen schlagen. Passt zu Memes und kleinen UI-Loops.

SVG (2001). Der Mechanismus: keiner, zumindest nicht im Raster-Sinn. SVG ist XML, das Formen, Pfade und Verläufe beschreibt, und der Renderer zeichnet die Pixel in der Auflösung, die der Bildschirm gerade braucht. Stärken: auflösungsunabhängig, winzig bei geometrischer Grafik, per CSS gestaltbar. Schwächen: funktioniert nur für Inhalte, die wirklich vektorbasiert sind, und pathologische Dateien mit Tausenden Knoten und schweren Filtern können teurer sein als eine Bitmap. Passt zu Logos, Icons, Diagrammen und Charts.

WebP (2010). Der Mechanismus: Der verlustbehaftete Modus leiht sich die Intra-Frame-Vorhersage vom Videocodec VP8, der verlustfreie Modus nutzt räumliche Vorhersage plus LZ77-artige Rückwärtsreferenzen. Stärken: beide Modi in einem Format, Alpha im verlustbehafteten Modus, Animation und 25 bis 34% kleinere Dateien als JPEG bei gleicher Qualität in Googles eigener Studie. Schwächen: eine harte Grenze von 16383 × 16383 Pixeln und ein Encoder, der mehr CPU frisst als libjpeg. Passt zu fast allem, weshalb es der Standard-Upgrade-Pfad für JPEG, PNG und GIF im Web wurde.

AVIF (2019). Der Mechanismus: Standbilder aus dem Videocodec AV1, verpackt im HEIF-Container. Stärken: die beste verlustbehaftete Komprimierung, die man in einen Browser liefern kann, grob 50% kleiner als JPEG bei gleicher Qualität in Netflix' Tests von 2020, dazu 10-Bit- und 12-Bit-Farben, HDR, Alpha und Animation. Schwächen: Die Kodierung ist wirklich langsam, es gibt kein progressives Rendering (das Bild erscheint auf einen Schlag oder gar nicht), und sehr niedrige Qualitätseinstellungen verwischen Texturen auf eine Weise, wie es JPEGs ehrliches Blocking nicht tut. Passt zu Fotos und Hero-Bildern, wo die Dateigröße am meisten zählt.

HEIC (2015). Der Mechanismus: HEVC-Standbilder, ebenfalls im HEIF-Container. Stärken: Komprimierung auf AV1-Niveau und Standard-Aufnahmeformat auf jedem iPhone seit 2017. Die Schwäche ist juristischer statt technischer Natur: HEVC ist in Patentpools verstrickt, und jeder Browser-Hersteller außer Apple lehnte es ab zu zahlen. Es gehört in Handy-Fotoalben, nicht ins Web.

JPEG XL (2021). Der Mechanismus: zwei Engines unter einem Dach, VarDCT für verlustbehaftete Arbeit und ein modularer Modus für verlustfrei, plus ein Trick, den kein anderes Format kann. Es kann ein bestehendes JPEG verlustfrei auf etwa 80% seiner ursprünglichen Größe rekomprimieren, Bit-exakte Pixel inklusive. Stärken: progressives Dekodieren, exzellente verlustfreie Raten, hochwertige Fotografie. Die Schwäche ist die Verbreitung, und das ist eine politische Geschichte, die weiter unten erzählt wird. Passt zu Foto-Pipelines und Archiven – und auf Apple-Geräten zum Web.

Browser-Support, Mitte 2026

Versionen, in denen jedes Format standardmäßig aktiviert wurde, laut caniuse-Daten:

Drei Details in dieser Tabelle sind erwähnenswert. AVIF kam auf iOS technisch gesehen schon in Safari 16.0, aber ohne Animation; voller Support auf macOS und iOS kommt erst mit 16.4. Edge lieferte AVIF Jahre nach Chrome aus, obwohl Edge Chromium ist, weil Microsoft den Decoder länger deaktiviert hielt als Google. Und die Zeile zu JPEG XL verbirgt eine ungewöhnliche Geschichte, die weiter unten ihren eigenen Abschnitt bekommt.

Globale Abdeckung, laut caniuse-Zahlen von 2026: WebP liegt bei etwa 97%, AVIF bei 93 bis 94%. JPEG und PNG stehen faktisch bei 100%, und daran dürfte sich nichts ändern.

Die Kompatibilitäts-Hierarchie

Nach Reichweite gruppiert, fallen die Formate in fünf Stufen.

Stufe eins ist das Universalset: JPEG, PNG, GIF und SVG. Sie dekodieren in jedem Browser, jedem E-Mail-Client, jeder OS-Vorschau und jedem jahrzehntealten Kiosk. Wenn eine Datei unbedingt aufgehen muss, wird sie in einem dieser vier Formate ausgeliefert.

Stufe zwei ist WebP, allein. Der letzte große Verweigerer war Safari, und Safari 14 schloss diese Lücke im September 2020. Übrig bleiben Internet-Explorer-Installationen und uralte Android-WebViews. Für eine Website – im Gegensatz zu einer E-Mail – ist WebP seit etwa fünf Jahren ein sicherer Standard.

Stufe drei ist AVIF. Chrome hatte es 2020, Firefox 2021, Safari 2022 (voller Support im März 2023 mit 16.4), und Edge aktivierte es im Januar 2024 standardmäßig. Seit Anfang 2024 dekodiert jede große Engine AVIF von Haus aus. Die verbleibenden paar Prozent sind ältere iPhones und unverwaltete Windows-Flotten, und genau dafür gibt es Fallbacks.

Stufe vier ist JPEG XL, festgefahren. Apple liefert es nativ seit Safari 17 im September 2023 aus. Google entfernte Chromiums experimentellen Decoder Ende 2022, wirksam mit Chrome 110 im Februar 2023, kehrte dann um und mergte einen Rust-basierten Decoder (jxl-rs), der mit Chrome 145 im Februar 2026 ausgeliefert wurde, immer noch hinter einem Flag. Firefox hat seit Jahren einen Decoder hinter einem Flag. JPEG-XL-Support Mitte 2026 bedeutet also: alle Apple-Nutzer plus der verschwindend kleine Anteil an Chrome- und Firefox-Nutzern, die Flags umlegen – eine Gruppe, zu klein, um darauf aufzubauen.

Stufe fünf ist HEIC: Safari 17 auf Apple-Plattformen, sonst nirgendwo irgendetwas. Das ist weniger eine Stufe als ein Single-Vendor-Ökosystem.

Was das Web wirklich ausliefert

Support ist nicht Nutzung. Der Web Almanac des HTTP Archive crawlt Millionen echter Seiten und zählt, was sie ausliefern, und die Ausgabe 2024 (die letzte mit vollständigen Mediendaten) liest sich wie ein sich bewegender Gletscher. JPEG war mit 32% aller Bilder immer noch das häufigste Einzelformat, aber das sind acht volle Punkte weniger als die 40% von 2022. WebP schnappte sich drei dieser Punkte und kam auf 12%. SVG legte etwa zwei zu. AVIF erreichte grob 1%, was nach Rundungsfehler klingt, bis man es relativ liest: fast 4-faches Wachstum in zwei Jahren. ICO hielt 1,3%, fast alles davon Favicons. Und GIF, 37 Jahre alt, gewann irgendwie einen Punkt dazu.

Warum bewegt es sich so langsam? Drei Reibungspunkte sind dafür hauptverantwortlich. CDN-Caching: Bilder liegen am Edge, über die URL adressiert, und ein Formatwechsel bedeutet Caches invalidieren und ganze Bibliotheken neu kodieren. Alte Geräte: Der Support-Chart sagt 97%, aber die fehlenden 3% konzentrieren sich auf billige Android-Handys und Firmenflotten, und manche Sites können es sich nicht leisten, auch nur einen einzigen Verkauf wegen eines kaputten Bildes zu verlieren. Tooling-Trägheit: Das CMS erzeugt JPEG-Thumbnails, weil es das immer getan hat, das Design-Tool exportiert PNG, weil das der große Button ist, und den Standard zu ändern heißt, eine Build-Pipeline anzufassen, die niemandem gehört.

Dazu kommen die Kodierkosten. AVIFs Komprimierungsvorteil wird zur Kodierzeit in CPU bezahlt, weshalb Bild-CDNs dafür Geld verlangen und kluge Teams AVIF beim Build oder Upload vorab erzeugen statt on the fly.

Wohin die Reise geht

AVIF ist die sicherste Wette für die nächsten Jahre. Es ist by design lizenzgebührenfrei (die Alliance for Open Media wurde 2015 von Amazon, Cisco, Google, Intel, Microsoft, Mozilla und Netflix explizit gegründet, um Patentpools nach HEVC-Art zu entkommen), behandelt verlustbehaftet und verlustfrei in einer Spezifikation, trägt HDR und hat die Support-Schwelle überschritten, ab der eine Fallback-Kette fast nichts mehr kostet. Die tatsächlichen Kosten sind Kodierzeit und das fehlende progressive Dekodieren. Vorgenerierung löst das Erste, das Zweite ist ein fairer Tausch.

JPEG XL hätte ein besseres Ergebnis verdient, als es bekommen hat. Technisch ist es das vollständigste Format, das je standardisiert wurde: progressives Dekodieren, der beste verlustfreie Modus, Fotografie mit hoher Bittiefe und die verlustfreie Rekomprimierung des gesamten existierenden JPEG-Korpus. Google entfernte es aus Chromium mit der Begründung unzureichenden Ökosystem-Interesses, und die Wiederherstellungs-Petition wurde eines der meistmarkierten Issues in der Geschichte des Chromium-Trackers. Drei Jahre später kehrte Google die Entscheidung um, aber da war das Adoptionsfenster bereits weitgehend geschlossen. Während JPEG XL im Exil saß, sammelte AVIF die CDN-Integrationen, die CMS-Plugins und die Standard-Häkchen ein. JPEG XL wird als Liebling der Archivare weiterleben und als First-Class-Format auf Apple-Geräten. Es hatte die technischen Argumente für den Mainstream und hat ihn trotzdem verpasst.

HEIC wird kein Webformat werden. Der Grund hat nichts mit Qualität zu tun. HEVC-Dekodierung erfordert Patentlizenzen, für die Hersteller kostenloser Browser seit einem Jahrzehnt nicht zahlen wollen, und das Web läuft auf lizenzfreier Technologie. Ein Format, das drei der vier großen Engines nicht dekodieren, ist kein Webformat; es ist ein Exportproblem, das du an der Grenze löst.

Die Übergangstechnik ist derweil gut etabliert und hat zwei Formen. Serverseitige Content Negotiation: Der Browser sendet einen Accept-Header, der auflistet, was er dekodieren kann, und Server oder CDN wählen für dieselbe URL die beste Variante. Clientseitig: das <picture>-Element, das Kandidaten auflistet und den Browser den ersten nehmen lässt, den er versteht:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

Das <img> unten ist der universelle Fallback, also geht nirgendwo etwas kaputt. So lieferst du AVIF an die 93% und JPEG an den Rest, ohne zwei Sites pflegen zu müssen.

Die Entscheidungstabelle

Eine kurze Favicon-Anmerkung, weil die Tabellenzeile einige Details auslässt. Moderne Browser akzeptieren PNG- und sogar SVG-Favicons, aber ICO bleibt das eine Format, das jeder Crawler, jeder RSS-Reader und jeder uralte Browser-Tab versteht, und eine ICO-Datei kann mehrere Größen in einem Container bündeln. Wenn dein Logo derzeit in einem anderen Format lebt, erzeugen JPG zu ICO, WebP zu ICO und PNG zu ICO direkt in deinem Browser ein sauberes Multi-Size-ICO.

Zwischen Formaten konvertieren

Die meisten Konvertierungsarbeiten ergeben sich aus den Abschnitten oben. Die bei Weitem häufigste ist, HEIC aus einem iPhone heraus und in etwas zu bringen, das der Rest der Welt öffnen kann. HEIC zu JPG ist der richtige Schritt zum Teilen, denn HEIC ist bereits verlustbehaftet, und JPEG verhindert, dass sich der Schaden summiert. HEIC zu PNG friert den aktuellen Zustand zur Bearbeitung ein, und HEIC zu WebP ergibt Sinn, wenn das Ziel eine Website ist.

Dann ist da das Dreieck aus JPEG, PNG und WebP. Ein JPEG in einen Design-Workflow überführen: JPG zu PNG, nicht weil es dadurch Qualität gewinnt (das kann es nicht), sondern weil es aufhört, weitere zu verlieren. Es fürs Web verkleinern: JPG zu WebP. In die andere Richtung für ältere Software: WebP zu JPG und WebP zu PNG. Ein PNG-Screenshot auf dem Weg in eine Fotogalerie: PNG zu JPG, oder PNG zu WebP, wenn du kleinere Dateien willst und die Transparenz erhalten bleiben soll. Wenn du unkomprimierte BMP-Scans erbst, schlagen BMP zu JPG, BMP zu PNG und BMP zu WebP allesamt das Verschicken von Mehr-Megabyte-Relikten per E-Mail. Selbst Dokumente landen an derselben Weggabelung: PDF zu JPG für fotografische Seiten, PDF zu PNG, wenn der Text gestochen scharf bleiben muss, und PDF zu WebP, wenn die Seite ins Web soll.

Jedes dieser Tools führt die Konvertierung lokal in deinem Browser aus, die Datei verlässt also nie dein Gerät.

Formate ändern sich ständig. Die Regel nicht: Passe den Codec an den Inhalt an, und konvertiere, wenn der Inhalt den Job wechselt.