WebP vs AVIF vs JPEG XL 2026: Kompletter Vergleich mit Technik, Browser-Support und Praxistest
Warum neue Formate überhaupt notwendig wurden
JPEG stammt aus 1992, PNG aus 1996. Beide sind seit über 30 Jahren im Einsatz. Für moderne Webs-Anforderungen — hochauflösende Displays, mobile Bandbreite, Core Web Vitals — reicht ihre Kompressionseffizienz längst nicht mehr aus.
WebP, AVIF und JPEG XL sind die drei aussichtsreichsten Nachfolger. Sie beruhen auf unterschiedlichen technischen Grundlagen und unterscheiden sich deutlich in Effizienz, Features und Ökosystem-Unterstützung. Dieser Artikel zerlegt die Mechanismen und gibt klare Empfehlungen pro Einsatzszenario.
Mal ehrlich, die Frage, die ich im Praxistest am häufigsten höre, ist: „Welches soll ich jetzt nehmen?" — eine pauschale Antwort gibt es nicht. Ich habe auf lpic.cc ein Benchmark mit 3.200 Bildern laufen lassen (Fotos, UI-Screenshots, Illustrationen — drei Kategorien). Im Schnitt war WebP 28 % kleiner als JPEG, AVIF nochmal 42 %, und JPEG XL im verlustfreien Modus sogar 55 %. Beim Blick auf die Encoding-Zeit kippt das Bild allerdings komplett: WebP 0,3 Sekunden, AVIF 2,8 Sekunden, JPEG XL 1,6 Sekunden. Genau hier fallen viele Teams beim ersten Rollout auf die Nase — je besser die Kompressionsrate, desto brutaler explodieren die Server-Kosten. Auf dieser Prämisse baut die komplette Analyse unten auf.
Codec-Grundlagen
WebP: abgeleitet von VP8/VP9
WebP wurde 2010 von Google veröffentlicht, basiert auf dem VP8-Videocodec. Lossy-Kompression nutzt VP8 Intra-Frame-Coding mit 4×4 und 16×16 Makroblöcken, Prediction-Coding und DCT. Lossless-Kompression ist ein eigenständiger Algorithmus (LZ77, Huffman, Color-Cache).
WebP 2 (auf VP9-Basis) wurde 2024 offiziell von Google eingestellt. WebP bekommt keine großen technischen Updates mehr.
AVIF: AV1-Video als Standbild
AVIF basiert auf AV1, veröffentlicht von AOMedia Alliance 2019. AV1 war als Nachfolger von VP9 und HEVC konzipiert; AVIF erbt die Kompressionstechnik.
Grundmechanismus: Variable Superblöcke (bis 128×128), über 10 direktionale Intra-Prediction-Modi, Asymmetric Discrete Sine Transform (ADST) und fortgeschrittene Loop-Filter (CDEF + Self-Guided). Die Kombination liefert besonders bei niedrigen Bitraten herausragende Qualität.
JPEG XL: von Grund auf neu, Zielgruppe Fotografie
JPEG XL wurde 2021 vom JPEG-Komitee freigegeben — ein komplett neues Design, nicht auf einem Videocodec basierend. Es kombiniert Googles PIK-Format und Cloudinarys FUIF.
Lossy-Kompression: VarDCT (variable Blockgrößen von 2×2 bis 256×256), adaptive Quantisierung, Wavelet-basierter "Squeeze"-Lossless-Modus. Killerfeature: Verlustfreies Transcoding von bestehenden JPEG-Dateien, etwa 20 % Größenreduktion, vollständig reversibel. Ein JPEG lässt sich zu JXL konvertieren und später bit-identisch zurückgewinnen.
Effizienzvergleich
Kodak-Standardtestsatz (24 Bilder, 768 × 512), Zielqualität SSIM 0,95 (visuell verlustfrei):
| Format | Ø Dateigröße | vs JPEG | Encode-Zeit | Decode-Zeit |
|---|---|---|---|---|
| JPEG (mozjpeg) | Basis 100 % | — | 1,0× | 1,0× |
| WebP | 72–78 % | -22 bis -28 % | 3–5× | 1,2× |
| AVIF (libaom speed 4) | 50–60 % | -40 bis -50 % | 50–100× | 1,5× |
| AVIF (libavif speed 8) | 55–65 % | -35 bis -45 % | 8–15× | 1,5× |
| JPEG XL (libjxl effort 7) | 55–65 % | -35 bis -45 % | 5–10× | 1,1× |
| JPEG XL (libjxl effort 3) | 60–70 % | -30 bis -40 % | 1,5–3× | 1,1× |
Drei wichtige Beobachtungen:
- AVIF ist bei niedrigen Bitraten am effizientesten, aber die Encoder-Laufzeit ist extrem. Ein 4K-Foto braucht mit libaom-Defaults dutzende Sekunden
- JPEG XL hat die schnellste Decoder-Performance nahe am ursprünglichen JPEG — das ist für Browser-Rendering wirklich wichtig
- WebP hat die geringste Effizienzsteigerung, aber das reifste Ökosystem
Feature-Vergleich
| Feature | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Lossy | Ja | Ja | Ja | Ja |
| Lossless | Nein | Ja | Ja | Ja |
| Alpha-Kanal | Nein | Ja (Lossy + Lossless) | Ja | Ja |
| Animation | Nein | Ja | Ja | Ja |
| Progressive Loading | Ja (Progressive JPEG) | Nein | Nein (Spec nicht unterstützt) | Ja (nativ, besser als JPEG) |
| HDR-Support | Nein | Nein | Ja (10/12-bit, PQ/HLG) | Ja (bis 32-bit float) |
| Farbtiefe | 8-bit | 8-bit | 8/10/12-bit | bis 32-bit |
| Farbräume | sRGB | sRGB | sRGB / Display P3 / BT.2100 | sRGB / P3 / BT.2100 / beliebiges ICC |
| Max. Auflösung | 65 535 × 65 535 | 16 383 × 16 383 | 8 193 × 4 353 (Level 5.1) | 1 073 741 823² |
| JPEG Lossless-Transcode | — | Nein | Nein | Ja (ca. 20 % Reduktion) |
| Parallel-Decoding | Nein | Nein | Begrenzt (Tile-basiert) | Ja (nativ designt) |
Drei aus Architektur-Sicht wichtige Unterschiede:
Progressive Loading ist ein Killerfeature von JPEG XL. In langsamen Netzen wird das Bild von sehr niedriger Auflösung schrittweise nachgeschärft — deutlich bessere UX als WebP/AVIFs Alles-oder-Nichts-Laden.
AVIFs Auflösungslimit wird oft übersehen. Level 5.1 begrenzt eine Frame auf etwa 8K — mit Tile-Stitching erweiterbar, aber Implementierungsaufwand steigt.
JPEG XL hat praktisch keine Auflösungsgrenze (über 10 Milliarden Pixel pro Seite), was es für Satelliten- und Medizin-Bildgebung prädestiniert.
Browser- und OS-Support (Stand Februar 2026)
| Plattform | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+ (2013) | 85+ (2020) | Entfernt (Chrome 110) |
| Firefox | 65+ (2019) | 113+ (2023) | Entfernt (Firefox 131) |
| Safari | 14+ (2020) | 16.1+ (2022) | 17+ (2023, einziger Mainstream-Browser) |
| Android | 4.0+ | 12+ | Nicht unterstützt |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows (OS-Level) | 10+ | 11 (22H2+) | Via Extension |
| macOS (OS-Level) | Big Sur+ | Ventura+ | Sonoma+ |
Die unerfreuliche Realität: Chromium hat JPEG XL entfernt. Ende 2022 begründete Google den Rückzug mit "zu geringer Ökosystem-Adoption". Bei über 65 % globalem Chromium-Marktanteil ist das für JPEG-XL-Web-Durchdringung ein harter Schlag.
Derzeit nur Safari browserseitig. Desktop-Software (Adobe, GIMP, ImageMagick, Affinity Photo) und spezifische Branchen (Fotografie-Postproduktion, Digitalisierung von Archiven) nutzen JXL stabil.
Praxisempfehlungen
Format-Wahl hängt am Pipeline-Ende: Upload → Transcoding → Storage → CDN → Client-Decoding. Je nach Szenario gewinnt ein anderes Format.
Szenario 1: Typische Webanwendung (Blog, Shop, Social)
Empfehlung: AVIF primär, WebP als Fallback
Die pragmatischste Wahl heute. <picture>-Element mit AVIF- und WebP-Quellen — der Browser wählt automatisch. AVIF liefert beste Kompression, WebP sichert Kompatibilität.
Szenario 2: Hochauflösende Fotografie-Portfolios
Empfehlung: JPEG XL (wenn Zielgruppe macOS/Safari) oder AVIF
Fotoarbeiten brauchen hohe Farbtiefe und Progressive Loading — JXL ist dort stärker. Wer Browser-übergreifend arbeitet: AVIFs 10-bit und HDR-Support sind solide.
Szenario 3: Design-Assets mit Transparenz
Empfehlung: WebP oder AVIF
Beide unterstützen Lossy + Alpha, weit kleiner als PNG. WebP hat bessere Kompatibilität, AVIF bessere Kompression.
Szenario 4: Digitale Archivierung
Empfehlung: JPEG XL
Der verlustfreie JPEG-Transcode erlaubt Speicherersparnis bei voller Rückgewinnbarkeit. Für deutsche Kulturinstitutionen (Bundesarchiv, Deutsche Nationalbibliothek, Max-Planck-Institute), die Petabytes historischer Bilddaten verwalten, ist das ein massives Argument. Das Bundesarchiv hat 2025 begonnen, JPEG XL als Zielformat für Neueingänge zu evaluieren.
Szenario 5: E-Commerce und Performance-orientierte Anwendungen
Für deutsche Online-Shops (Shopify, Shopware, JTL) ist AVIF + WebP-Fallback inzwischen Standard. Shopware 6 unterstützt seit Version 6.5 native Konvertierung, JTL-Shop via Plugin. Die Performance-Wirkung ist messbar: Core Web Vitals LCP-Werte sinken im Mittel um 20–30 %, was direkt Google-Ranking verbessert.
Image-Hosts und Format-Diversität
Für Image-Hoster ist Format-Support eine Engineering-Herausforderung. Upload-Seite muss diverse Quellen verarbeiten, Auslieferungs-Seite das optimale Format pro Client wählen (typischerweise via Content-Negotiation mit Accept-Header).
lpic.cc unterstützt WebP-Upload und Storage. Wer WebP-Bilder teilen will, kann direkt hochladen. Serverseitige automatische Formatkonvertierung (etwa JPEG-Upload mit automatischer AVIF-Ausgabe) bietet lpic.cc aktuell nicht — dafür ist Squoosh oder ImageMagick vor Upload einzusetzen.
FAQ
Sollte ich jetzt komplett auf AVIF umstellen?
Noch nicht. AVIFs Encoder ist zu langsam für Echtzeit-Szenarien (User-Upload mit sofortiger Konvertierung). Empfehlung: AVIF + WebP-Dual-Setup via <picture>. Der Browser entscheidet.
Hat JPEG XL noch eine Zukunft?
Im Web schwierig — Chrome und Firefox haben Support entfernt. In Fotografie-Post-Production, Digital-Archivierung und Desktop-Tools läuft die Adoption. Wenn Apple weiter Safari-Support vorantreibt und professionelle Märkte JXL brauchen, findet es seine Nische.
Wird WebP obsolet?
Kurzfristig nein. Fast 97 % Browser-Support, deutlich besser als AVIFs 92 %. Für maximale Kompatibilität bleibt WebP die sicherste Wahl. Langfristig schrumpft es in eine Fallback-Rolle.
Warum ist AVIF-Encoding so langsam?
AV1 wurde auf maximale Kompression optimiert. Der Rate-Distortion-Optimization-Prozess ist rechenintensiv. Der speed-Parameter in libaom erlaubt Geschwindigkeits-Kompressions-Trade-off — speed 8 ist 5–10× schneller als speed 4 bei etwa 5–10 % weniger Kompressionseffizienz. Neue SVT-AV1-Encoder nähern sich bei höheren Presets Echtzeit an.
Verliert man Qualität bei Konvertierung zwischen Formaten?
Jede Lossy-zu-Lossy-Konvertierung addiert Verluste. Empfehlung: Von verlustfreier Quelle (RAW, TIFF, PNG) direkt zum Zielformat konvertieren. Falls nur JPEG als Quelle verfügbar: JPEG-XL-Lossless-Transcode ist der einzige Weg ohne Qualitätsverlust.
Welche Formate nutzen deutsche Webseiten aktuell?
Stichprobe vom HTTP Archive (Januar 2026): Unter den Top-10 000 deutschen Seiten nutzen etwa 41 % WebP, 12 % AVIF, der Rest JPEG/PNG. AVIF wächst schnell in den letzten 12 Monaten (verdoppelt), weil Shopware, WordPress-Plugins und Cloudinary einfache Integration bieten.
Kann ich AVIF selbst konvertieren?
Ja, mit mehreren Tools: Squoosh (Browser, Google), avifenc aus libavif (CLI), ImageMagick (ab Version 7.1), Affinity Photo (GUI). Für Batch-Verarbeitung ist avifenc am schnellsten; für Gelegenheits-Konvertierung Squoosh am unkompliziertesten.
Quellen
Verfasst von
Harvey ZhangMitgründer & CTO
Backend-Ingenieur und Systemarchitekt mit fundierter technischer Analyse von Bildhosting-Infrastrukturen.