WebP 2026: Browser-Support, Größengewinn, sinnvolle Fallbacks

WebP ist seit Google ihn 2010 vorgestellt hat ein Format, dem man die Adoption-Phase ansieht. Erst lag der Support bei einem Drittel der Browser, dann bei der Hälfte, dann eskalierte er mit Safari 14 im September 2020. Heute, 2026, ist die Lage so eindeutig wie sie nie war: WebP läuft in allen Browsern, die nennenswerten Marktanteil haben. Die Frage ist nicht mehr ob, sondern wie sauber man umstellt.

Browser-Coverage 2026 in Zahlen

Die wichtigste Quelle bleibt caniuse.com. Stand Mai 2026 sieht der globale Anteil für WebP so aus:

Browser	Coverage	Seit Version
Chrome, Edge	100 Prozent	Chrome 32 (2014)
Firefox	100 Prozent	Firefox 65 (2019)
Safari (macOS)	100 Prozent	Safari 14 (2020)
Safari (iOS)	100 Prozent	iOS 14 (2020)
Samsung Internet	100 Prozent	4.0 (2016)
Andere mobile WebViews	meist 100 Prozent	unterschiedlich

In der globalen Statistik kommt das auf 97 bis 98 Prozent. Im deutschsprachigen Raum eher höher, weil hier weniger alte Android-Geräte aktiv sind als in manchen anderen Märkten. Wer also überlegt, ob man WebP überhaupt ausliefern darf: kann man, fast immer.

Wie viel kleiner ist das wirklich

Google selbst nennt in den Original-Benchmarks 25 bis 34 Prozent kleinere Dateien gegenüber JPEG bei gleicher Wahrnehmungsqualität. Das deckt sich grob mit dem, was man in der Praxis misst, ist aber nicht das Ende der Geschichte. Drei Faktoren beeinflussen den Gewinn massiv:

Motiv. Glatte Farbverläufe (Himmel, Studio-Porträt) komprimiert WebP deutlich besser. Sehr rauschige Fotos (Nacht, hohe ISO) bringen weniger Vorteil, weil das Rauschen für jeden Codec teuer ist.

Quality-Stufe. Die Skalen sind nicht direkt vergleichbar. WebP-Quality 75 entspricht ungefähr JPEG-Quality 82. Wer 1:1 die Zahl überträgt, ist bei WebP entweder zu großzügig oder zu sparsam. In der Praxis: für Web-Output WebP-Quality 72 bis 78 ansetzen.

Source-Datei. Wer WebP aus einem schon stark komprimierten JPEG erzeugt, bekommt nicht den vollen Gewinn, weil die Detailinformation bereits weg ist. Idealerweise WebP aus PNG oder hochqualitativem JPEG (Quality 95+) ableiten.

Konkrete Beispiele aus einem Test mit 50 Web-typischen Fotos (Landschaft, Produkt, Porträt, Lifestyle):

• JPEG-Quality 80 zu WebP-Quality 75: WebP im Schnitt 28 Prozent kleiner
• JPEG-Quality 90 zu WebP-Quality 82: WebP im Schnitt 32 Prozent kleiner
• PNG zu WebP-Lossless: WebP im Schnitt 22 Prozent kleiner als optimiertes PNG

Das bedeutet konkret: ein 800 KB JPEG-Hero wird zum 560 KB WebP. Über zehn Bilder pro Seite sind das knapp 2,5 MB weniger, die durch die Leitung müssen. Für mobile Verbindungen ist das spürbar.

Das <picture>-Element als sauberes Fallback

Trotz 98 Prozent Coverage lohnt sich ein Fallback. Nicht für Endnutzer-Browser, sondern für Edge-Cases: alte In-App-Browser, manche Crawler, Mail-Vorschau in älteren Outlook-Versionen. Der Aufwand ist gering:

<picture>
  <source srcset="/img/produkt.webp" type="image/webp" />
  <img src="/img/produkt.jpg" alt="Produktfoto" loading="lazy" width="800" height="600" />
</picture>

Der Browser nimmt das erste <source>, dessen type er versteht. Kennt er WebP, wird die .webp-Variante geladen, sonst das JPEG. Wichtig: width und height am <img> setzen, sonst gibt es Layout-Shift, und Performance-Tools penalisieren das. Auch loading="lazy" lohnt sich für alles, was nicht im sofort sichtbaren Bereich liegt.

Wer noch einen Schritt weitergehen will, ergänzt AVIF davor:

<picture>
  <source srcset="/img/produkt.avif" type="image/avif" />
  <source srcset="/img/produkt.webp" type="image/webp" />
  <img src="/img/produkt.jpg" alt="Produktfoto" loading="lazy" width="800" height="600" />
</picture>

Das ist 2026 in der Tat eine sinnvolle Reihenfolge für trafficstarke Bilder. Bei kleinen Bildern (Thumbnails, Icons) lohnt sich der zusätzliche AVIF-Build dagegen meist nicht, weil der Encoding-Aufwand pro Bild groß ist und der absolute Größengewinn klein.

Was tools heute liefern

Es gibt drei pragmatische Wege, WebP zu produzieren:

Direkt im Browser. Der Bild-Kompressor auf bild-komprimieren.de bietet das an, ohne Upload auf einen Server. Das Bild bleibt auf dem Rechner, was beim Datenschutz hilft (siehe auch der Ratgeber zu EXIF und DSGVO).

Über die Kommandozeile (cwebp). Googles offizielles Tool, frei verfügbar. Aufruf cwebp -q 78 input.jpg -o output.webp. Gut für Skripte und Massenkonvertierung.

Im Build-Pipeline-Tool. sharp (Node.js), Vips, Imagemagick mit WebP-Delegate, Astro Image-Service, Next.js Image-Komponente. Alle erzeugen WebP-Varianten automatisch und liefern bei Bedarf auch direkt das passende <picture>-Markup. Für Sites, die ohnehin mit einem statischen Site-Generator gebaut werden, ist das der gleitende Übergang.

Wann WebP nichts bringt

Drei Fälle, in denen WebP keinen messbaren Vorteil hat:

• Sehr kleine Bilder (unter ~5 KB Original). Der Header-Overhead frisst den Komprimierungsgewinn auf.
• Bilder, die später ohnehin nicht im Browser angezeigt werden. PDF-Export, Print-Pipelines, Druckereien arbeiten weiter mit TIFF oder JPEG.
• E-Mail-Versand. Outlook 2019 und ältere zeigen WebP teilweise nicht oder ersetzen den Inline-Anhang. Für E-Mail-Templates bleibt JPEG die sichere Wahl.

Für alle anderen Web-Anwendungsfälle ist WebP 2026 ein klares Plus. Die Coverage ist da, der Größengewinn ist real, das Fallback kostet drei Zeilen HTML. Wer noch nicht umgestellt hat, schiebt eine schnelle Optimierung vor sich her.