WebP-Browser-Support: wo es läuft und wie du Fallbacks baust

WebP hat sich vom Nischenformat zum Alltagsstandard entwickelt. Wer heute eine Webseite baut, kann in aller Regel davon ausgehen, dass Besucher das Format sehen. Trotzdem hält sich hartnäckig die Sorge, WebP sei “noch nicht überall angekommen”. Das war vor Jahren berechtigt, ist es heute aber nur noch in klar abgrenzbaren Randfällen. Genau diese Randfälle sind der Grund, warum du das Format kennen und trotzdem einen Fallback einplanen solltest.

In diesem Ratgeber gehst du zwei Fragen durch: Wo läuft WebP zuverlässig, und wo hakt es noch? Danach bekommst du die Standardlösung an die Hand, mit der du beide Welten bedienst, ohne dass ein einziger Besucher ein kaputtes Bild sieht. Der Code dafür ist kurz, robust und seit Jahren Best Practice.

Der aktuelle Stand: WebP läuft praktisch überall

Fangen wir mit der guten Nachricht an, denn sie ist die wichtigere. Alle großen Browser unterstützen WebP für die Anzeige von Bildern. Google Chrome kann das Format schon seit den frühen 2010er-Jahren, was wenig überrascht, da WebP von Google selbst stammt. Chromium-basierte Browser wie das heutige Microsoft Edge, Opera, Brave und Vivaldi teilen sich diese Basis und können WebP entsprechend ebenfalls.

Der lange fehlende Baustein war jahrelang Firefox, doch Mozilla hat die Unterstützung mit Firefox 65 Anfang 2019 nachgezogen. Der letzte große Holdout war Safari. Apple hat WebP mit Safari 14 im Herbst 2020 aktiviert, gebündelt mit macOS Big Sur und iOS 14. Damit war der Kreis der relevanten Browser geschlossen. Seither ist WebP nach den gängigen Kompatibilitätsdaten für den allergrößten Teil des weltweiten Web-Traffics verfügbar.

Praktisch heißt das: Wenn ein Besucher in den letzten Jahren sein Betriebssystem oder seinen Browser auch nur einmal aktualisiert hat, sieht er WebP. Die theoretische Lücke ist klein, aber sie ist nicht null, und die Lücke sitzt an unangenehmen Stellen, die dir bei einem reinen Webseiten-Blick leicht entgehen.

Browser	WebP-Anzeige ab	Ungefähres Jahr
Chrome	Version 32 (Basis früher)	2010er
Firefox	Version 65	2019
Edge (Chromium)	Version 18/79	2018/2020
Opera	Version 19	2013
Safari (macOS)	Version 14, Big Sur	2020
Safari (iOS)	iOS 14	2020

Wo es trotzdem noch hakt

Die Browser-Statistik erzählt nur die halbe Geschichte. Ein Bild landet nicht nur in Browsern, sondern in einer ganzen Kette von Programmen, und einige davon sind bei WebP wählerischer.

Der erste Fall sind schlicht sehr alte Systeme. Ein Windows 7 mit Internet Explorer zeigt kein WebP, ebenso wenig ältere Android-Versionen mit dem alten Stock-Browser oder ein iPhone, das aus welchen Gründen auch immer auf iOS 13 oder früher festhängt. Solche Geräte sind selten, aber in bestimmten Zielgruppen, etwa bei behördlicher oder industrieller IT mit langen Update-Zyklen, durchaus real.

Der zweite und oft unterschätzte Fall sind E-Mail-Clients. Wer ein WebP direkt in eine HTML-Mail einbindet, riskiert, dass es in Outlook-Versionen oder manchen Webmail-Oberflächen einfach nicht erscheint. E-Mail-Rendering hinkt der Browser-Entwicklung traditionell weit hinterher. Für Newsletter und transaktionale Mails bleibt JPG oder PNG deshalb die sichere Wahl.

Der dritte Fall betrifft Programme abseits des Browsers. Ältere Bildbetrachter, in die Jahre gekommene Office-Versionen oder bestimmte PDF-Workflows nehmen ein WebP nicht ohne Weiteres an. Wenn du also ein Bild verschickst, das der Empfänger lokal öffnen, in ein Dokument einbetten oder ausdrucken soll, ist WebP ein Risiko, das du nicht eingehen musst.

Der vierte Fall sind Upload-Felder. Manche Social-Media-Plattformen, Marktplätze, Bewerbungsportale oder Vereins-Websites akzeptieren beim Upload ausschließlich JPG oder PNG und weisen WebP mit einer Fehlermeldung ab. Das ist kein Anzeigeproblem, sondern eine Format-Whitelist auf der Serverseite, und dagegen hilft kein Browser-Trick, sondern nur ein Bild im geforderten Format. Besonders ärgerlich ist dieser Fall, weil er oft erst im letzten Moment auffällt, etwa wenn du dein Profilbild aktualisieren oder ein Produktfoto einstellen willst und der Upload kommentarlos scheitert. Wer weiß, dass die Datei ein WebP ist, kann sie in Sekunden zurück nach JPG wandeln, doch wer die Ursache nicht kennt, sucht den Fehler oft an der falschen Stelle.

Die Konsequenz aus diesen vier Fällen ist unbequem, aber klar: Für die reine Webanzeige kannst du dich auf WebP verlassen. Sobald das Bild diesen Kontext verlässt, brauchst du eine JPG-Version in der Hinterhand. Genau deshalb ist es praktisch, wenn du jederzeit schnell zwischen den Formaten wechseln kannst, ohne eine schwere Software zu installieren. Mit dem Konverter hier auf jpgwebp.de wandelst du deine Bilder direkt im Browser um, ohne Upload und ohne dass eine Datei dein Gerät verlässt.

Die Standardlösung: das picture-Element

Für die Webanzeige gibt es eine elegante Antwort auf das Fallback-Problem, und sie ist im HTML-Standard fest verankert: das <picture>-Element. Die Idee dahinter ist einfach. Du bietest dem Browser mehrere Bildquellen an, und er nimmt die erste, die er versteht. Versteht er WebP, lädt er das kleinere WebP. Versteht er es nicht, fällt er automatisch auf das JPG zurück. Der Besucher merkt von diesem Aushandeln nichts, er sieht immer ein Bild.

So sieht das im Markup aus:

<picture>
  <source srcset="/bilder/urlaub.webp" type="image/webp" />
  <img src="/bilder/urlaub.jpg" alt="Sonnenuntergang am Strand" width="1200" height="800" />
</picture>

Wichtig ist die Reihenfolge und die Rollenverteilung. Die <source> mit type="image/webp" steht oben. Der Browser prüft diesen Typ, und nur wenn er WebP darstellen kann, lädt er die dort angegebene Datei. Kann er es nicht, ignoriert er die Zeile und geht zum <img> weiter. Das <img> am Ende ist keine Dekoration, sondern die tragende Säule: Es liefert das JPG als Fallback, trägt das alt-Attribut für Barrierefreiheit und Suchmaschinen und ist zugleich das Element, das ganz alte Browser sehen, die mit <picture> selbst nichts anfangen können. Ohne dieses <img> funktioniert die Konstruktion nicht.

Ein Detail, das sich lohnt: Gib immer width und height am <img> an. Damit reserviert der Browser den Platz für das Bild schon vor dem Laden und verhindert das nervige Nachrutschen des Layouts. Das ist gut für die wahrgenommene Geschwindigkeit und wird auch bei den Core Web Vitals belohnt, wie du im Ratgeber zu WebP, Web-Performance und SEO nachlesen kannst.

Das gleiche Muster funktioniert übrigens nicht nur für WebP gegen JPG, sondern für jedes Bildformat, das du absichern willst. Du kannst mehrere <source>-Zeilen stapeln, etwa ein noch moderneres Format ganz oben, WebP in der Mitte und das JPG als letzte Rückfallebene im <img>. Der Browser arbeitet die Liste von oben nach unten ab und nimmt die erste Quelle, die er versteht. Für die meisten Projekte reicht die Kombination aus WebP und JPG völlig aus, weil sie mit zwei Dateien pro Bild bereits vom schnellsten bis zum ältesten Besucher alle abdeckt. Mehr Formate bedeuten mehr Varianten, die dein Build-Prozess erzeugen und pflegen muss, und dieser Aufwand rechnet sich nur, wenn der Zusatznutzen die Mühe wert ist.

Was der Fallback dich kostet, und was nicht

Ein berechtigter Einwand lautet: Wenn ich sowieso ein JPG vorhalten muss, warum dann der Aufwand mit WebP? Die Antwort liegt im Verhalten des Browsers. Er lädt nur eine der beiden Dateien, nicht beide. Ein moderner Browser holt sich das WebP und ignoriert das JPG vollständig, es entsteht also kein doppelter Datenverkehr für den Besucher. Der Geschwindigkeitsvorteil von WebP kommt bei den allermeisten Nutzern voll an, während die wenigen mit alten Systemen sauber das JPG bekommen.

Der Preis ist also nicht die Bandbreite, sondern die Pflege. Du hast pro Bild zwei Dateien statt einer, und dein Build-Prozess oder dein CMS muss beide erzeugen und ausliefern. In der Praxis übernimmt das ein automatisierter Schritt, sodass du die WebP-Variante nicht von Hand pflegen musst. Wie groß der eigentliche Gewinn an Dateigröße ausfällt und wie WebP im direkten Vergleich abschneidet, zeigt der Formatvergleich JPG gegen WebP im Detail.

Für die Praxis ergibt sich eine klare Faustregel. Nutze WebP überall dort, wo du die Auslieferung selbst kontrollierst, also auf deiner eigenen Website mit <picture>-Fallback. Bleibe bei JPG, sobald du das Bild aus der Hand gibst und nicht weißt, welches Programm es öffnet, sei es per Mail, per Upload oder als Datei zum Weitergeben.

Content-Negotiation auf dem Server

Es gibt noch einen zweiten, unsichtbaren Weg, WebP auszuliefern, der ohne verändertes Markup auskommt: die serverseitige Content-Negotiation. Jeder Browser schickt bei einer Anfrage einen Accept-Header mit, der verrät, welche Formate er versteht. Ein Chrome sendet darin unter anderem image/webp, ein sehr alter Browser tut das nicht.

Ein entsprechend konfigurierter Server oder ein CDN kann diesen Header auswerten und unter derselben Bild-URL entweder ein WebP oder ein JPG zurückgeben, je nachdem, was der anfragende Browser signalisiert hat. Für den Seitenautor bleibt es bei einem simplen <img src="/bilder/urlaub.jpg">, die Umwandlung passiert im Hintergrund. Das ist bequem, weil du im HTML nichts ändern musst, verlagert die Komplexität aber in die Serverkonfiguration und erfordert, dass die Zwischenspeicher korrekt nach dem Accept-Header trennen. Für kleinere Projekte ist das <picture>-Element meist der einfachere und besser nachvollziehbare Weg, für große Bildmengen kann die Content-Negotiation die elegantere Lösung sein.

Ehrliches Fazit: JPG-Fallback ist Pflicht

Bleiben wir bei der Wahrheit, auch wenn sie unspektakulär ist. WebP ist für die Webanzeige heute ein sicheres Format, und du solltest es aus Performance-Gründen nutzen. Die Zeiten, in denen ein Besucher mit aktuellem Browser ein leeres Bild sah, sind vorbei.

Trotzdem ist der JPG-Fallback keine Nostalgie, sondern Pflicht, wenn du maximale Kompatibilität willst. Die Lücken sitzen nicht mehr in den Browsern, sondern an den Rändern: in E-Mails, in alten Programmen, in Upload-Whitelists und auf Systemen, die seit Jahren kein Update gesehen haben. Ein <picture>-Element mit sauberem <img>-Fallback kostet dich zwei Zeilen mehr Markup und schützt dich vor genau diesen Fällen, ohne dass du auf den Geschwindigkeitsvorteil verzichtest.

Die praktische Konsequenz ist einfach: Halte immer beide Formate bereit. Auf der Website spielst du WebP mit JPG als Rückfallebene aus, und für alles, was die Website verlässt, greifst du zum JPG. Wenn du wissen willst, wie WebP technisch überhaupt zu seiner geringen Dateigröße kommt und was der Qualitätsregler dabei bewirkt, lohnt ein Blick in die Grundlagen zum WebP-Format. Und wann immer du kurzfristig eine JPG- oder WebP-Version brauchst, wandelst du sie hier auf jpgwebp.de direkt im Browser um, ohne Upload und ohne Datenabfluss.

Hast du einen Fehler entdeckt oder einen Quellen-Hinweis für uns? Schreib gern an info@akara-solutions.de.