2010: Ein Codec sucht einen Markt

Die Geschichte von WebP beginnt nicht in einer Bildbearbeitungs-Abteilung, sondern in einem Video-Codec-Labor. Im August 2009 hatte Google für 124 Millionen Dollar On2 Technologies übernommen, einen Codec-Spezialisten aus Clifton Park, New York, der vor allem für seine VPx-Codec-Familie (VP3, VP6, VP7) bekannt war. Der eigentliche Kauf-Treiber war VP8 — ein damals brandneuer Video-Codec, der mit H.264 konkurrieren konnte und den Google für YouTube-Auslieferung lizenz-frei haben wollte.

Im Mai 2010 stellte Google das aufgekaufte VP8 als Open-Source-Spezifikation frei und gründete das WebM-Projekt für Video-Auslieferung. Im selben Atemzug demonstrierte Google-Ingenieur Jyrki Alakuijala, dass sich die VP8-Intraframe-Komprimierung (also die Komprimierung einzelner Frames ohne Bewegungs-Vektoren) auch für Standbilder verwenden lässt. Das Ergebnis hieß WebP und wurde am 30. September 2010 als Bildformat veröffentlicht — fünf Monate nach der VP8-Freigabe.

Der technische Kern: VP8-Intraframes

WebP-Lossy verwendet im Kern dieselben Algorithmen wie ein einzelner Video-Frame in VP8. Das Bild wird in 16×16-Pixel-Makroblöcke zerlegt, prädiktive Codierung schätzt Pixel-Werte aus benachbarten Blöcken vor, die Differenz wird per DCT (analog zu JPEG) quantisiert, und ein arithmetischer Coder packt die Restdaten. Anders als JPEGs Huffman-Codierung erlaubt die arithmetische Codierung feinere Bit-Allokation, was bei vergleichbarer Qualität typisch 25–35 % kleinere Dateien ergibt.

Diese Verwandtschaft zu einem Video-Codec ist gleichzeitig WebPs Stärke und seine Limitierung. Stärke: Video-Codecs müssen extrem effizient pro Bit sein, weil 30 Frames pro Sekunde sonst keine Bandbreite überlebt — diese Effizienz steht jetzt Standbildern zur Verfügung. Limitierung: 16×16-Makroblöcke sind für lebende Szenen ausgelegt, nicht für Diagramme oder Pixel-Art; bei diesen Inhalten ist die Effizienz-Gewinne kleiner und PNG bleibt im Vorteil.

2011: Der Lossless-Modus

Ein Jahr nach dem Launch fügte Google einen verlustfreien Modus hinzu — der mit der ursprünglichen VP8-Pipeline nichts mehr zu tun hatte. WebP-Losslessist eine vollständig eigene Spezifikation, entworfen von Jyrki Alakuijala und Vincent Rabaud, die auf prädiktiver Codierung mit größeren Blöcken, Farb-Transformation und einer LZ77-artigen Komprimierung basiert. Das Ergebnis: bei Grafiken typisch 20–40 % kleinere Dateien als optimiertes PNG.

Damit war WebP das erste populäre Bildformat, das sowohl verlustbehaftete als auch verlustfreie Komprimierung in einer einzigen Datei-Hülle bot — ein Konzept, das später AVIF und JPEG XL übernahmen. Eine Detail-Analyse dazu in unserem PNG-vs.-WebP-Vergleich.

2012–2014: Browser-Adoption-Trockenphase

Trotz technischer Vorteile passierte zwischen 2012 und 2014 wenig. Chrome und Opera unterstützten WebP von Anfang an — beides Google-Verwandte. Aber Firefox, Safari, Internet Explorer und Edgeverweigerten die Implementierung. Die Gründe waren teils technisch (man wollte warten, bis sich das Format stabilisiert hatte), teils politisch (Apple und Microsoft hatten kein Interesse, Googles Format-Initiativen zu legitimieren).

Die paradoxe Folge: Web-Entwickler mussten ein Format ausliefern, das nur ein Teil ihrer Besucher sehen konnte. Der <picture>-Tag, der seit 2014 als HTML-Standard offiziell verfügbar war, wurde zur Pflicht-Technik für jeden, der WebP nutzte: Erst WebP-Source angeben, dann JPG-Fallback für die anderen 50 % der Browser.

2016: Animation und Alpha

2016 erweiterte Google WebP um zwei wichtige Features. Animationmachte WebP zum direkten GIF-Konkurrenten, mit deutlich besseren Eigenschaften: 24-Bit- Farbtiefe statt 8-Bit, echte Alpha-Transparenz pro Pixel und Interframe-Coding (nur die veränderten Pixel zwischen Frames werden gespeichert). Ein typisches 5-MB-GIF wird als animiertes WebP zu 1,2 MB — gleiche Animation, bessere Qualität, ein Viertel der Bytes. Die volle Gegenüberstellung findest du in unserem GIF-vs.-WebP-Beitrag.

Alpha im Lossy-Modus war die zweite Erweiterung: vorher konnten nur verlustfreie WebPs Transparenz; danach konnten auch Lossy-WebPs Alpha-Pixel speichern, mit eigenem Bit-Budget für den Alpha-Kanal. Damit wurde WebP zur einzigen Datei-Hülle, die JPG (verlustbehafteter Foto-Modus) und PNG (verlustfreier Grafik-Modus) zugleich ersetzen konnte.

2018–2020: Die letzten Browser fallen

Firefox implementierte WebP Anfang 2019. Edge war schon 2020 vollständig auf Chromium umgestellt, also dabei. Der entscheidende Schritt kam im September 2020: Safari 14 (macOS Big Sur, iOS 14) lieferte erstmals native WebP-Unterstützung. Damit war WebP nach genau einem Jahrzehnt in jedem relevanten Browser angekommen — und konnte ohne Fallback-Logik ausgespielt werden.

Die Caniuse-Statistik zeigte 2021 das erste Mal über 95 % Browser-Coverage. Spätestens ab da war es Best Practice, neue Web-Bilder primär als WebP zu liefern und JPG nur noch als optionalen Fallback für extrem alte Systeme.

libwebp und die Sicherheitslücke 2023

Wie bei jedem dominanten Bild-Decoder hatte WebP seinen Sicherheits-Skandal. Im September 2023 wurde CVE-2023-4863 öffentlich — ein Heap-Buffer-Overflow in libwebp, der Remote-Code-Execution erlaubte. Weil libwebp in praktisch jedem modernen System steckt (Chrome, Firefox, Safari, Electron, iOS, macOS, Android), war das einer der breitesten Single-Library-Patch-Roll-Outs der jüngeren Internet-Geschichte. Innerhalb von Tagen erschienen Updates für alle Mainstream-Browser; Citizen Lab dokumentierte, dass die Lücke in Israel-Spyware aktiv ausgenutzt worden war.

Aus dem Vorfall lernten Browser-Hersteller eine pragmatische Lektion: Bild-Decoder gehören in Sandboxes. Chrome hatte das schon vorher, Firefox und Safari folgten 2024 mit konsistenter Process-Isolation für Decoder-Bibliotheken.

WebP 2026: Standard, aber nicht das Letzte Wort

Heute ist WebP der pragmatische Standard für Web-Bilder. Es wird von jedem Browser unterstützt, jede CMS-Plattform liefert es automatisch aus, Smartphone-Galerien können es lesen und schreiben. Aber AVIF und JPEG XL drücken nach. AVIF (siehe unseren AVIF-Beitrag) liefert nochmal 20–30 % kleinere Dateien, JPEG XL hat strukturelle Vorteile für Archive und progressives Laden.

WebP bleibt vorerst der „sichere Default" — robuste Implementierungen, überall-vorhandene Hardware-Beschleunigung, klare Effizienz-Gewinne gegenüber JPG. Unser WebP-Komprimierer nutzt libwebp via WebAssembly browser-lokal; mehr Hintergründe zu Encoder-Tuning im großen WebP-Guide.

Wann WebP die richtige Wahl ist

  • Web-Auslieferung im breiten Markt. 97 % Browser-Coverage, klare Bytes-Ersparnis gegenüber JPG/PNG.
  • UI-Sprites mit Transparenz. WebP-Lossless ersetzt PNG mit 20–40 % kleineren Dateien.
  • Animationen statt GIF. Drei- bis vierfache Bytes-Ersparnis bei besserer Qualität.
  • E-Commerce-Produktfotos. Faster Page Load, besseres Lighthouse-Score, siehe E-Commerce-Optimierung.

Wann WebP nicht ideal ist: Druck-Workflows (Druckereien akzeptieren oft nur klassische Formate), maximale Effizienz (AVIF und JPEG XL sind kleiner), und sehr alte Backup-Software, die WebP nicht öffnen kann.

Quellen

Google Developers — WebP-Spezifikation · RFC 6386 — VP8 Data Format and Decoding Guide · RFC 9649 — WebP Image Format · libwebp-Quellcode · CVE-2023-4863 — libwebp Heap Buffer Overflow · Can I Use — WebP Browser-Support · Google Inc., „Lossless and Transparency Encoding in WebP", 2011 (Whitepaper).