JPG vs. WebP: 25 % kleinere Dateien bei gleicher Qualität

Kurzfassung. WebP schlägt JPG fürs Web, weil es bei gleicher Bildqualität 25–35 % kleinere Dateien erzeugt und dabei Transparenz und Animation unterstützt – bei ~97 % Browser-Abdeckung 2026. JPG gewinnt nur bei E-Mail-Anhängen, Druck-Pipelines und Altsoftware.

WebP ist ein von Google entwickeltes Bildformat, das 2010 eingeführt und bis 2020 in jeden großen Browser aufgenommen wurde. Bei gleicher Bildqualität erzeugt es 25–35 % kleinere Dateien als JPG. Für die meisten Web-Ziele gibt es keinen verbleibenden Grund, standardmäßig JPG zu wählen; das einzige relevante Hindernis – Browser-Support – ist Stand 2026 im Wesentlichen gelöst.

Die Kernzahlen

Wann WebP gewinnt

• Web-Ziel, modernes Browser-Publikum. Standardmäßig WebP. Die 3 % der Browser ohne Support können über das <picture>-Element (siehe unten) auf JPG zurückfallen.
• Fotografien mit Transparenz. JPG kann Alpha überhaupt nicht. WebP schon – und bei kleineren Größen, als PNG es könnte.
• Mobile-first, bandbreitenbewusstes Publikum. 25–35 % kleinere Dateien bedeuten spürbar schnellere Seitenladungen bei getakteten Verbindungen.

Wann JPG noch gewinnt

• E-Mail-Anhänge. Manche E-Mail-Programme (uraltes Outlook, bestimmte Webmail-Varianten) verarbeiten WebP noch fehlerhaft. JPG ist universell.
• Druck-Pipelines. Die meiste Prepress-Software akzeptiert JPG nativ; WebP-Support ist uneinheitlich.
• Einbettung in Alt-CMS oder Dokumentvorlagen, die ihr nicht testen oder aktualisieren könnt.
• Kamera-Ausgabe. Die meisten Kameras schreiben standardmäßig noch JPG. Konvertiert zu WebP im Veröffentlichungs-, nicht im Aufnahmeschritt.

Das picture-Element-Fallback

Für maximale Reichweite mit WebPs kleineren Dateien nutzt HTMLs<picture>-Element mit Format-Fallbacks. Der Browser wählt die erste <source>, die er unterstützt; das <img> dient als Allzweck-Fallback für Browser, die <picture> gar nicht kennen.

<picture>
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="…" />
</picture>

Modernes Chrome / Safari / Firefox / Edge bekommen WebP; der kleine verbleibende Anteil bekommt JPG. Der Build-Schritt muss beide Versionen erzeugen, ansonsten ist das Markup nur eine Zeile mehr.

Soll ich mir auch AVIF antun?

AVIF (2019) ist der Nachfolger: 20–30 % kleiner als WebP bei gleicher Qualität. Der Browser-Support liegt 2026 bei ~93 % – gut genug für dasselbe Fallback-Muster, mit drei Stufen:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="…" />
</picture>

AVIFs Haken ist die Kodiergeschwindigkeit – typische Encoder sind 10- bis 100-mal langsamer als WebP. Für Build-Pipelines, die jedes Bild einmal erzeugen (Web-Veröffentlichung), lohnt das Warten. Für spontane Kodierung (Uploads, nutzergenerierte Inhalte) ist WebP die praktische Wahl.

Die pragmatische Empfehlung

Standardmäßig WebP für Web-Ziele. Behaltet das JPG-Fallback über<picture> für die lange Reihe alter Browser. Fügt AVIF als dritte Stufe hinzu, wenn ihr eine Build-Pipeline habt, die es günstig erzeugen kann. Konvertiert eure bestehende JPG-Bibliothek mit unserem JPG-zu-WebP-Konverter – läuft in eurem Browser, kein Upload, dauert Sekunden pro Datei.

Zahlen-Fakten

• WebP vs. JPG Dateigröße: Googles eigene Studie über 1 Million Bilder maß eine mediane Reduktion von 25–34 % bei abgeglichenem SSIM, wobei verlustfreies WebP im Schnitt 26 % kleiner war als PNG.
• Farbtiefe: JPG ist nur 8 Bit pro Kanal (24 Bit gesamt); WebP unterstützt dieselben 8 Bit verlustbehaftet plus 8 Bit verlustfrei mit Alpha; keines kann HDR – das ist AVIF- (10–12 Bit) und JPEG-XL-Gebiet.
• Maximale Abmessungen: JPG ist 65.535 × 65.535 px (16-Bit-Felder); WebP ist 16.383 × 16.383 px (14 Bit) – der eine Punkt, an dem JPG technisch gewinnt.
• Eingesparte Alpha-Bytes: ein 1080p-PNG mit Alpha liegt im Schnitt bei ~600 KB; das äquivalente verlustbehaftete WebP-mit-Alpha landet bei ~80 KB – etwa 7-mal kleiner als die einzige Alternative der JPG-Ära (PNG).
• Kodierzeit: libjpeg-turbo kodiert ~250 MP/s; libwebp verlustbehaftet ~80 MP/s; libwebp verlustfrei ~20 MP/s auf einem 2024er-Laptop. JPG ist ~3-mal schneller zu kodieren, Dekodier-Parität innerhalb von 10 %.
• Browser-Abdeckung (caniuse.com, 2026): WebP ~97,4 %, AVIF ~93 %, JPEG XL <1 % (Chrome/Edge ließen es 2023 fallen).

Direkter Vergleich: gleiches Quellbild bei Qualität 80

Entscheidungsmatrix

Quellen

• Google WebP Study – WebP Compression Study – developers.google.com/speed/webp/docs/webp_study.
• RFC 9649 – The WebP Image Format – rfc-editor.org/rfc/rfc9649.
• caniuse.com Browser-Support-Matrix für image/webp – caniuse.com/webp.