WebP vs AVIF vs JPEG: Welches Bildformat gewinnt 2026?

TL;DR: AVIF ist 20–30 % kleiner als WebP und 30–50 % kleiner als JPEG. WebP ist rund 25–35 % kleiner als JPEG. AVIF encodet 5–20× langsamer als WebP, während WebP von den dreien am schnellsten decodiert. Der gewinnende Workflow für 2026: AVIF zuerst ausliefern, auf WebP zurückfallen, JPEG als universelles Sicherheitsnetz behalten und den Browser über das <picture>-Element wählen lassen.

Diese Antwort deckt die meisten Leser ab. Die spannendere Frage ist, wann man besser nicht zu AVIF greift. Lassen Sie es bei knappen CI-Budgets weg, wo Encode-Zeit mehr zählt als Bytes. Halten Sie es bei Echtzeit-Uploads von Nutzern zurück, da browserseitiges AVIF-Encoding noch lückenhaft ist. Behalten Sie JPEG als Primärformat, wenn Sie iOS 16.0–16.3 oder älteres Edge im Feld unterstützen müssen. Überall sonst gewinnt AVIF bei der Dateigröße, vorausgesetzt Ihr <picture>-Markup stimmt und Ihr CDN sendet den korrekten MIME-Typ.

Der Rest dieses Leitfadens ist die praktische Detailarbeit: Support-Zahlen für 2026, ein Benchmark mit echtem Foto, ein Entscheidungsbaum nach Anwendungsfall, kopierfertige <picture>-Muster, Konvertierungs-Befehle und die vier Fallen, die Teams Zeit kosten. Wenn Sie nur die Konvertierung erledigt haben wollen: Unser kostenloser Bildkomprimierer verarbeitet JPEG, PNG, WebP und AVIF im Browser, ohne irgendetwas hochzuladen.

1. Browser-Support 2026: WebP bei 97 %, AVIF bei 93 %

Zweieinhalb Jahre nachdem Edge AVIF ausgeliefert hat, ist die Support-Lücke auf wenige Prozent des globalen Traffics geschrumpft. Die Frage lautet nicht mehr „Wird es unterstützt?”, sondern „Was liefern wir an die letzten 3 %?“.

1.1 WebP: der sichere Standard

WebP wurde 2012 in Chrome, in Firefox 65 (2019), Edge 18 (2018) und Safari 14 (2020) ausgeliefert. Stand Mai 2026 weist caniuse den globalen Support bei rund 97 % aus. WebP hat sich von der „modernen Alternative” zum „tragfähigen Fallback” weiterentwickelt. Wenn Sie ein einzelnes Nicht-JPEG-Format ausliefern, ist WebP die Wahl.

1.2 AVIF: jetzt als Primärformat einsetzbar

AVIF kam in Chrome 85 (August 2020) und Firefox 93 (Oktober 2021). Safari 16.4 hat es im März 2023 auf macOS und iOS aktiviert. Edge war der Nachzügler und hat Decode-Support erst in 121 (Januar 2024) hinzugefügt. Die globale Abdeckung im Mai 2026 liegt bei rund 93–95 %.

Eine Kante, die man kennen sollte: iOS 16.0–16.3 hat einen bekannten AVIF-Decode-Bug, der Safari bei bestimmten Bildern zum Absturz bringen kann. Diese Builds laufen noch auf Geräten, die durch Enterprise-MDM zurückgehalten werden, sodass AVIF ohne funktionierenden WebP- oder JPEG-Fallback ein echtes Ausfall-Risiko darstellt. Setzen Sie AVIF also nur mit Versicherung ein, niemals allein.

1.3 Schnelle Kompatibilitätsmatrix

Format	Globaler Support (Mai 2026)	Wesentliche Einschränkung
JPEG	100 %	Größte Dateien; keine Transparenz; kein HDR
WebP	~97 %	Kein HDR, keine 10-Bit-Farbe
AVIF	~93–95 %	Langsames Encoding; iOS-16.0–16.3-Decode-Bug; benötigt Edge 121+

2. Kernunterschiede: Kompression, Geschwindigkeit, Funktionen

2.1 Kompressionseffizienz an einem echten Foto

Ein Benchmark mit identischer Quelle. Eine Landschaftsaufnahme mit 4000×3000, Original-PNG rund 24 MB, neu encodet bei wahrnehmbar gleicher Qualität:

Encoding	Größe	Vs. JPEG-Baseline
JPEG q75 (mozjpeg)	~2,1 MB	0 % (Baseline)
WebP q75 (libwebp)	~1,4 MB	33 % kleiner
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52 % kleiner

AVIF q60 ist hier visuell äquivalent zu JPEG q80 und WebP q75. Qualitätsskalen sind zwischen Codecs nicht austauschbar. Das Re-Encoding von „JPEG q75 nach AVIF q75” ist der klassische Anfängerfehler: Sie landen bei einem überdimensionierten AVIF, das identisch zur Quelle aussieht.

2.2 Encoding-Geschwindigkeit: die 5–20×-Steuer

AVIF komprimiert stärker, weil es mehr Arbeit leistet. Mit libavif beim Standard cpu-used 4 benötigt ein 4000×3000-Bild 5–20× länger als libwebp und rund 50× länger als mozjpeg. Diese Kosten potenzieren sich über CI-Builds, Lambda-Cold-Starts und Pipelines, die Tausende Assets neu encoden.

Es gibt zwei Notausgänge. cavif --speed 9 (oder libavif cpu-used 9) kommt auf das 3-Fache von libwebp heran, zum Preis von 5–8 % größeren Dateien. Und Caching aggressiv einsetzen: Eine inhaltsadressierte Asset-Pipeline, die unveränderte Quellen vom Re-Encoding ausnimmt, verwandelt einen langsamen Codec in einmalige Kosten.

2.3 Farbtiefe und HDR

JPEG und WebP enden bei 8-Bit sRGB. AVIF unterstützt 10- und 12-Bit-Farbe, Rec. 2020, DCI-P3 sowie PQ/HLG-Übertragungsfunktionen nativ. Für HDR-Video-Thumbnails, professionelle Fotogalerien oder browserseitige Druckproofs ist AVIF heute die einzige standardisierte Option.

2.4 Transparenz und Animation

JPEG hat weder das eine noch das andere. WebP und AVIF unterstützen beide Alpha und Animation. Speziell beim Ersatz transparenter PNGs encodet AVIF Alpha kompakter: Eine UI-Illustration, die als WebP um 30–40 % schrumpft, schrumpft als AVIF oft um 50–70 %.

3. Entscheidungsbaum: Welches Format für welche Aufgabe

3.1 Statische Sites: Blogs, Marketing-Seiten, Docs

AVIF primär, WebP-Fallback, JPEG-Sicherheitsnetz. Das Encoding passiert einmalig in CI, sodass die 5–20×-Steuer in Build-Zeit bezahlt wird, nicht in Nutzerzeit. Das ist der kanonische Fall für das Drei-Source-<picture>-Muster in Abschnitt 4.

3.2 Nutzer-Uploads: Avatare, UGC, Formular-Anhänge

Im Browser zu WebP komprimieren, serverseitig asynchron zu AVIF re-encoden. Browserseitiges canvas.toBlob('image/avif') funktioniert heute nur in Chrome 99+, sodass AVIF nicht der Upload-Pfad sein kann. WebP komprimiert schnell im Browser und spart Bandbreite beim eigentlichen Upload.

Für einen tieferen Vergleich clientseitiger Bibliotheken (Squoosh, browser-image-compression, Compressor.js) und wie sie sich mit serverseitigem Sharp oder Imagemin koppeln, siehe den Schwester-Beitrag Bildkomprimierung: Browser vs. Node.js — Leitfaden. Format-Wahl und Verarbeitungsort sind orthogonal; dieser Leitfaden behandelt die Format-Achse.

3.3 HDR und High-Fidelity-Fotografie

Nur AVIF. Nichts anderes im offenen Web-Stack unterstützt heute 10- oder 12-Bit-Farbe. Lassen Sie den Fallback bei HDR-only-Assets weg, oder akzeptieren Sie, dass der JPEG-Fallback SDR ist.

3.4 Zielgruppen mit vielen Legacy-Browsern

JPEG primär, WebP optional, kein AVIF. Behördenportale, bestimmte ostasiatische Enterprise-Umgebungen und B2B-Tools mit langen Geräte-Tails zeigen in Analytics manchmal 5–10 % IE-/Old-Edge-Traffic. WebP ist mittlerweile sicher; AVIF noch nicht.

3.5 Echtzeit-CDN-Auslieferung

Serverseitiges libvips oder Sharp streamt WebP, während AVIF auf einem Hintergrund-Worker erzeugt und bei Cache-Hit ausgeliefert wird. Blockieren Sie die Antwort nicht durch AVIF-Encoding. Cloudflare Polish, Vercel Image Optimization und Cloudinary f_auto automatisieren dieses Muster.

4. Der `<picture>`-Fallback, richtig gemacht

Das <picture>-Element existiert genau deshalb, damit der Browser die beste unterstützte Quelle wählen kann. Drei Schichten, AVIF zuerst aufgelistet, geben Ihnen das optimale Byte-Budget, ohne auf älteren Clients zu brechen.

4.1 Die Drei-Schichten-Baseline

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Ein paar Dinge, die man sich dabei merken sollte. Der Browser geht <source>-Elemente von oben nach unten durch und wählt das erste, dessen type er versteht; alles andere wird ignoriert, nicht heruntergeladen. Das <img>-Tag ist das tatsächlich gerenderte Element und erbt Attribute (alt, sizes, classes), egal welche Source gewinnt. Und width/height am <img> sind 2026 nicht optional, sie reservieren Platz und verhindern Cumulative Layout Shift.

Tauschen Sie für Above-the-fold-Bilder loading="lazy" gegen loading="eager" fetchpriority="high" aus. Lazy-Loading des LCP-Bildes ist eine der häufigsten Core-Web-Vitals-Stolperfallen.

4.2 Responsive plus Format: das vollständige Muster

Wenn Sie zusätzlich responsive Auflösungen brauchen, wiederholen Sie srcset innerhalb jedes <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Ja, das sind neun generierte Dateien pro Bild. Ein Build-Schritt ist in dieser Größenordnung nicht verhandelbar; Abschnitt 5.3 deckt ab, was sich einbinden lässt.

4.3 Serverseitige `Accept`-Aushandlung als Alternative

Wenn Ihr CDN dies unterstützt, schrumpft Content-Negotiation das Markup auf ein einzelnes <img>-Tag. Der Browser sendet Accept: image/avif,image/webp,image/apng,*/* und das CDN antwortet mit dem besten unterstützten Format unter derselben URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto und CloudFront mit Lambda@Edge implementieren das alle. Der Trade-off: kleineres HTML und eine URL pro Bild, aber CDN-Lock-in und mühsameres lokales Debugging. Eine sinnvolle Aufteilung lautet CDN-Aushandlung für Marketing-Seiten, explizites <picture> für die Produkt-UI, wo deterministisches Verhalten zählt.

5. Wie Sie Bilder zwischen Formaten konvertieren

5.1 Im Browser, ohne Upload

Der schnellste Weg für eine Einzelaufgabe oder einen kleinen Batch ist Browser-only. Ziehen Sie ein JPEG in den kostenlosen Bildkomprimierer, wählen Sie WebP oder AVIF als Ausgabe, und die Datei verlässt Ihre Maschine nie. AVIF-Eingabe wird überall unterstützt; AVIF-Ausgabe nutzt natives Browser-Encoding in Chrome 85+ und fällt transparent auf WebP zurück, wenn der Browser AVIF noch nicht encoden kann.

5.2 Kommandozeile für Build-Pipelines

Für eine Produktions-Pipeline wollen Sie deterministische Ausgabe und reproduzierbare Builds. Diese drei Befehle sind real:

# AVIF: cavif (Rust, einfach via cargo oder brew installiert)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (offizielles Google libwebp)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Beides plus Resize via libvips (am schnellsten für Batches)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed läuft von 0 (am langsamsten, am kleinsten) bis 10 (am schnellsten, am größten). Der Standard 4 ist der Sweet Spot für Nightly-Builds; gehen Sie auf 9 hoch für PR-Previews, wo Geschwindigkeit Bytes schlägt.

5.3 Build-Pipeline-Integration

Die meisten Static-Site-Frameworks umschließen diese Encoder bereits. Wählen Sie das, das zu Ihrem Stack passt:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programmatisch — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Bei winzigen Assets (Icons unter etwa 5 KB, Inline-Avataren, E-Mail-Headern) sparen Sie sich das Netzwerk komplett und betten als Data-URI per Base64-Kodierung ein. Das tauscht einen HTTP-Request gegen ein paar zusätzliche Bytes HTML, in der Regel ein Gewinn unterhalb von ~5 KB.

Wenn Sie zwischen client- und Node-seitigen Komprimierungs-Bibliotheken (Sharp vs. Squoosh vs. browser-image-compression) wählen, geht der Bildkomprimierung: Browser vs. Node.js — Leitfaden tiefer auf Benchmarks und Trade-offs ein.

6. Fallstricke und Missverständnisse

6.1 „AVIF gewinnt immer”: nicht bei Screenshots und Strichgrafik

AVIFs Stärken liegen bei kontinuierlich-tönigen Fotografien. Bei Screenshots mit scharfer Schrift, UI-Aufnahmen und Pixel-Art produziert WebP bei gleicher Qualität oft kleinere Dateien. AVIFs Deblocking kann zudem subtiles Banding in flachen Farbflächen erzeugen. Lassen Sie Konvertierungen in beide Richtungen laufen und wählen Sie pro Asset-Klasse den Sieger.

6.2 „Lossless WebP ersetzt transparente PNG perfekt”: fast, nicht identisch

WebP-Lossless ist tatsächlich kleiner als PNG, typischerweise um etwa 26 %. Der Haken: „Lossless” gilt für das komprimierte Bild, aber der Encoder kann immer noch Alpha-Kanal-Rundung in Bereichen mit hohem Gradienten verändern. Für pixelgenaue Reproduktion (medizinische Bildgebung, Archiv-Assets, alles, was rechtlich der Quelle entsprechen muss) bleiben Sie bei PNG. Für alles andere ist WebP-Lossless ein Netto-Gewinn.

6.3 „Einfach .avif-Dateien hochladen”: Ihr CDN weiß vielleicht nicht, was sie sind

Ältere nginx- und Apache-Konfigurationen sind älter als AVIF. Wenn /etc/nginx/mime.types image/avif avif; nicht aufführt, liefert nginx AVIF als application/octet-stream aus. Der Browser sieht den falschen Content-Type, weigert sich das Bild zu rendern und fällt still auf JPEG zurück, womit die gesamte Optimierung zunichtegemacht ist. Curlen Sie Ihre Asset-URL nach dem Deploy und prüfen Sie den Content-Type-Header. Fünf Sekunden Paranoia ersparen Ihnen eine Woche „Warum ist AVIF in Produktion kaputt?“.

6.4 Der iOS-16.0–16.3-AVIF-Crash

Manche AVIF-Dateien lösen unter iOS 16.0–16.3 einen Safari-Decode-Crash aus. Der Bug ist in 16.4 (März 2023) behoben, aber Enterprise-MDM und langsame OEM-Updates halten ältere Geräte am Leben. Mitigation: Liefern Sie nie AVIF ohne eine funktionierende WebP-Source im selben <picture> aus und setzen Sie nie ein AVIF direkt als <img>-src. Wer den Mustern aus Abschnitt 4 folgt, ist bereits geschützt.

7. Der Spickzettel für 2026

Szenario	Primär	Fallback	Encoder
Statische Marketing-Seiten	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp in CI
Blog-Beiträge und Docs	WebP q75	JPEG q80	kostenloser Bildkomprimierer (manuell) oder Sharp (Build)
Nutzer-Uploads	WebP (clientseitig)	JPEG (Browser ohne WebP-Encode)	browser-image-compression + serverseitiges Sharp für AVIF
HDR / Profi-Fotografie	AVIF 10-Bit q70	(keiner — SDR-Fallback weglassen oder AVIF ganz überspringen)	cavif + libavif HEIF-Modus
Echtzeit-CDN-Auslieferung	Ausgehandelt (AVIF oder WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Zwei Erinnerungen vor dem Ausliefern. Setzen Sie immer width und height am <img>, um CLS zu verhindern. Und prüfen Sie nach dem Deploy den Production-Content-Type-Header an mindestens einer AVIF-Antwort: Kaputte MIME-Konfiguration killt AVIF in Produktion still und häufiger als jeder andere Fehler auf dieser Liste.

FAQ

Brauche ich 2026 noch einen JPEG-Fallback?

Ja. AVIF erreicht rund 93 % der globalen Nutzer, WebP etwa 97 %. Damit bleibt eine kleine, aber reale Population (altes Edge, Firefox unter 93, iOS vor 16.4, plus die iOS-16.0–16.3-Bug-Zone), die JPEG braucht. Lassen Sie JPEG nur fallen, wenn Ihre Analytics effektiv null Traffic von diesen Browsern zeigen und Sie das belegen können.

Wie halte ich CI-Builds schnell, wenn AVIF-Encoding langsam ist?

Es gibt drei Hebel. Verwenden Sie cavif --speed 6 oder höher (Standard ist 4), um ~5 % Größe gegen ~3× Geschwindigkeit zu tauschen. Parallelisieren Sie über Cores mit GNU parallel oder dem Worker-Pool Ihres Build-Tools. Und cachen Sie nach Content-Hash, sodass unveränderte Quellbilder den Encoder komplett überspringen. Zusammen drücken diese Maßnahmen die AVIF-Build-Zeit gewöhnlich unter die alte single-threaded WebP-Baseline.

Ist WebP-Decoding wirklich schneller als AVIF?

Ja. libwebp decodiert rund 2–3× schneller als libavif, und die Lücke wächst auf Low-End-Mobilgeräten. Wenn Ihr Performance-Engpass beim Decode liegt (etwa eine lange Bildergalerie auf einem günstigen Android-Handy) statt beim Netzwerk, ist WebP das bessere Primärformat. Für den meisten Web-Traffic dominieren aber die Netzwerk-Einsparungen, und AVIF gewinnt insgesamt trotzdem.

Können iPhone-Nutzer AVIF sehen?

iPhones unter iOS 16.4 (März 2023) oder neuer unterstützen AVIF nativ in Safari. Geräte unter iOS 16.0–16.3 haben einen dokumentierten Decode-Bug, der Safari bei bestimmten AVIF-Dateien zum Absturz bringen kann; ältere iOS-Versionen unterstützen AVIF überhaupt nicht. Liefern Sie immer einen WebP- oder JPEG-Fallback im <picture> aus, damit betroffene Nutzer überhaupt etwas sehen.

Soll ich `<picture>` oder Accept-Header-Aushandlung verwenden?

Kleinere Projekte profitieren von explizitem <picture>-Markup: Das Verhalten ist deterministisch, lokales Debugging klappt sauber, und es kostet vielleicht 80 zusätzliche Bytes HTML pro Bild. Hochfrequentierte Sites gewinnen mit CDN-seitiger Accept-Aushandlung: eine URL pro Bild, automatische Format-Upgrades, und das CDN cached jedes Format separat. Eine verbreitete Hybrid-Lösung ist <picture> für die App-UI und CDN-Aushandlung für Marketing-Assets.

Warum wurde mein PNG nach der WebP-Konvertierung größer?

Fast immer, weil das Quell-PNG bereits aggressiv von pngquant, oxipng oder ZopfliPNG optimiert war und der Canvas-basierte Encoder des Browsers mit diesen Tools nicht mithalten kann. Encoden Sie aus dem Original neu (Photoshop-Export, Design-Tool-Master, RAW) statt aus dem optimierten PNG. Wenn das optimierte PNG Ihre einzige Quelle ist, ist das Original bereits nahezu optimal; lassen Sie es in Ruhe.

Unterstützt AVIF Transparenz?

Ja. AVIF unterstützt einen vollständigen 8- bis 12-Bit-Alpha-Kanal, und sein Alpha-Encoding ist im Allgemeinen kompakter als das von WebP. Eine transparente PNG-Illustration, die nach AVIF konvertiert wird, schrumpft typischerweise um 50–70 %, gegenüber 30–40 % als WebP. AVIF ist der stärkste Ersatz für transparente PNG in jedem Kontext, der keine pixelgenaue verlustfreie Ausgabe verlangt.

Können Browser AVIF nativ via toBlob(‘image/avif’) encoden?

Aktuell nur Chrome 99+. Safari und Firefox können AVIF zwar decodieren, aber nicht via Canvas-APIs encoden, Stand Mai 2026. Für clientseitiges AVIF-Encoding brauchen Sie derzeit WebAssembly-Bibliotheken wie libavif-wasm oder jsquash, die 1–2 MB Payload hinzufügen. Die meisten Produktions-Stacks komprimieren im Browser zu WebP und übergeben die AVIF-Erzeugung an einen Server-Worker.