Warum ein komprimiertes Bild größer wird und was hilft

Sie haben ein Bild durch einen Kompressor oder Konverter geschickt, und die heruntergeladene Datei ist größer als die, mit der Sie angefangen haben. Meist ist das kein Fehler: Ein Encoder beschreibt die Pixel, die er bekommt, im gewünschten Format, und diese Beschreibung fällt manchmal länger aus als die alte.

Kurz gesagt: Die Datei wächst, wenn die neuen Einstellungen mehr behalten als die alte Datei (ein stark komprimiertes JPEG, das mit höherer Qualität neu gespeichert wird), wenn ein verlustbehaftetes Foto in ein verlustfreies Format wandert (JPG zu PNG), wenn der Encoder einen Trick des Originals weglässt (ein Paletten-PNG, das als 32-Bit-Datei neu gespeichert wird), wenn der Format-Overhead bei einem winzigen Bild überwiegt oder wenn die Pixelzahl steigt. In unseren Tests wurde aus einem JPEG mit 135 kB ein PNG mit 2,21 MB, und aus einem Icon mit 504 Bytes wurde ein WebP mit 1.104 Bytes. Abhilfe schafft meist, das Original zu behalten, ein anderes Format zu wählen oder die Qualität zu senken. Welche Lösung wann passt, steht in den Abschnitten unten.

Die neun Fälle im Überblick

Jede Zahl stammt aus einem einzigen Durchlauf auf unserem Rechner. Die Größen sind exakte Bytes; im Text steht 1 kB für 1.000 Bytes.

So haben wir getestet

Alle Messungen liefen am 16. Oktober 2026 (UTC) auf einem Apple-M4-Mac mit macOS 26.6.2.

• Browser-Encoder: Google Chrome 155.0.8059.85 im Headless-Modus. Wir haben browser-image-compression 2.0.2, die Bibliothek hinter unserem Bildkompressor, in eine leere lokale Seite geladen und mit den Standardeinstellungen des Kompressors aufgerufen: Qualität 0,8, Zielgröße 1 MB, längste Seite höchstens 1.920 px, Originalformat beibehalten, EXIF entfernt und bis zu 30 Wiederholungsdurchläufe. Die Konverter-Fälle nutzen dieselben Canvas-Aufrufe wie unsere Konverterseiten: Bild zeichnen, für JPG einen weißen Hintergrund darunterlegen, dann canvas.toBlob mit der Standardqualität der Konverter von 90 %. Durch die Website selbst haben wir uns nicht geklickt; die Codepfade sind dieselben, aber die Seite drumherum war eine Testseite.
• Andere Encoder: sharp 0.35.5 unter Node v26.12.0 (libvips 8.18.7, mozjpeg, libwebp 1.6.0, libaom 3.15.1, libimagequant 2.4.1, libpng 1.6.58) sowie upng-js 2.1.0, der PNG/APNG-Encoder, den unser GIF-zu-APNG-Konverter aufruft.
• Bilder: ein CC0-Landschaftsfoto von Bonnie Moreland (Wikimedia Commons), entnommen aus der Ausgabe unseres Kompressors in einem früheren Benchmark (1920 × 1280, 250.382 Bytes), dazu eine mozjpeg-Neukodierung davon mit Qualität 70 (135.151 Bytes); das Kodak-Testbild kodim04 (PNG mit 512 × 768, von Kodak zur uneingeschränkten Nutzung freigegeben); ein Screenshot unserer eigenen Seite /compress (PNG mit 1440 × 900); das CC0-Logo „NEW LOGO R“ von Enzy Cell (Wikimedia Commons) und eine Palettenversion davon; ein Icon mit 32 × 32 Pixeln und ein GIF mit 12 Frames, beide für diesen Test selbst gezeichnet; und ein 320 px breites Vorschaubild, ausgeschnitten aus kodim04.

Jeder Wert stammt aus einem Durchlauf. Der PNG-Encoder des Browsers liefert nicht bei jedem Lauf byte-identische Dateien, wer den Test wiederholt, sieht also kleine Abweichungen. Wir entwickeln ImgCompress.app selbst; wer dahintersteht, steht auf der Über-uns-Seite. Ein KI-Assistent hat beim Entwurf des Textes geholfen, und wir haben jede Zahl mit den Rohdateien abgeglichen.

Warum wird ein JPEG beim erneuten Komprimieren größer?

Weil „Qualität 80“ keine feste Kompressionsstärke ist. Die Zahl ist eine Einstellung für einen bestimmten Encoder, und verschiedene Encoder oder verschiedene Qualitätswerte behalten unterschiedlich viel Detail.

Unser Test-JPEG mit 135 kB war mit mozjpeg bei Qualität 70 erzeugt worden, einer Einstellung für möglichst kleine Dateien. Als der eingebaute Encoder von Chrome es mit Qualität 80 neu speicherte, kamen 168 kB heraus, 24 % mehr. Der Browser hatte das JPEG zu einfachen Pixeln dekodiert, samt dem blockigen Kompressionsrauschen, das mozjpeg hinterlassen hatte, und diese Pixel dann mit feinerer Quantisierung kodiert als das Original. Was beim ersten Mal verloren ging, kommt nicht zurück; die neue Datei verwendet nur mehr Bytes auf dasselbe Bild plus die alten Artefakte.

Die weniger stark komprimierte Fassung desselben Fotos mit 250.382 Bytes verhielt sich anders. Chrome mit Qualität 80 lieferte 250.670 Bytes, nur 288 Bytes mehr. Mit demselben Encoder und derselben Einstellung neu gespeichert, mit denen die Datei entstanden war, landete sie fast genau bei der Originalgröße.

Was unser Kompressor dagegen tut

Unser Kompressor prüft das erste Ergebnis. Ist die Ausgabe in browser-image-compression größer als die Quelle (oder größer als die Zielgröße), kodiert die Bibliothek erneut mit dem 0,95-Fachen der vorherigen Qualität (bei PNG mit dem 0,85-Fachen) und wiederholt das, bis die Datei unter beiden Grenzen liegt oder die Durchläufe aufgebraucht sind. Die Maße schrumpfen in dieser Schleife nur, wenn die Datei über der Zielgröße liegt; ein kleines Foto behält also seine Pixelmaße.

Bei der Datei mit 250 kB brachte ein zusätzlicher Durchlauf mit Qualität 0,76 sie auf 240.546 Bytes, 3,9 % weniger. Bei der mozjpeg-Datei mit 135 kB waren sieben Durchläufe bis hinunter zu Qualität 0,56 nötig, um auf 134.643 Bytes zu kommen. Das sind 508 gesparte Bytes für eine deutlich niedrigere Qualitätseinstellung an einer Datei, die schon komprimiert war. Zeigt die Ergebniskarte eine Ersparnis von ein paar Prozent oder weniger, behalten Sie besser das Original.

Ist das Ergebnis danach immer noch nicht kleiner und hat sich das Format nicht geändert, gibt Ihnen der Kompressor die Originaldatei zurück. Im selben Format bekommen Sie von ihm also nie eine größere Datei.

Ausführlicher erklärt unser Leitfaden zur JPEG-Komprimierung, was hinter den Qualitätswerten steckt.

Warum ist das PNG nach der Umwandlung aus JPG so viel größer?

PNG ist verlustfrei. Das Format speichert jedes Pixel exakt, und ein dekodiertes JPEG-Foto hat viele Pixel, die leicht von ihren Nachbarn abweichen: Filmkorn, Sensorrauschen und das schwache 8-×-8-Blockmuster, das die JPEG-Kompression hinzufügt. Ein verlustfreies Format muss all das mitspeichern.

Je stärker das JPEG komprimiert war, desto größer fiel der Sprung in unserem Test aus, denn die Ausgangsdatei war kleiner, während das PNG weiterhin dieselbe Anzahl Pixel speichern musste. Die Umwandlung in PNG macht außerdem keinen JPEG-Schaden rückgängig. Sie bekommen dieselbe Unschärfe und dieselben Blöcke, nur jetzt verlustfrei gespeichert.

Wandeln Sie JPG in PNG um, wenn Sie wirklich PNG brauchen: für ein Programm, das nur PNG annimmt, für eine Arbeitskopie, die Sie oft bearbeiten, oder für ein Formular, das JPG ablehnt. Geht es um eine kleinere Datei, bleiben Sie bei JPG oder wechseln Sie zu WebP oder AVIF.

Warum ist mein PNG nach dem Neuspeichern gewachsen?

Im Browser arbeiten hier zwei Dinge gegen Sie.

Erstens packte der PNG-Encoder im Canvas von Chrome die Daten deutlich weniger dicht als die Datei, die er bekommen hatte. Das kodim04-Foto über canvas.toBlob neu zu speichern, machte aus 637.432 Bytes 846.413 Bytes, 33 % mehr, bei identischen Pixeln. Selbst ein sorgfältiges verlustfreies Neuspeichern gewinnt nicht automatisch: sharp mit libpng auf Kompressionsstufe 9 erzeugte 638.304 Bytes, 872 Bytes mehr als die Ausgangsdatei.

Zweitens hält ein Canvas jedes Bild als 32-Bit-RGBA, und genau so schrieb Chrome es auch heraus. Ein Paletten-PNG speichert jedes Pixel als Verweis auf eine kleine Farbtabelle; so kommen Tools wie TinyPNG und pngquant zu ihren kleinen Dateien. Unsere Palettenversion des Logos hatte 45.525 Bytes. Auf einen Canvas gezeichnet und neu gespeichert, wurden daraus 170.429 Bytes, 3,7-mal so viel, weil die Farbtabelle weg war und jedes Pixel vollständig gespeichert wurde.

Für PNG verwendet unser Kompressor kein einfaches canvas.toBlob. browser-image-compression übergibt die Pixel an UPNG, mit einer Farbgrenze von 4096 mal der Qualität, also 3.276 Farben beim Standardwert 0,8. Die Ergebnisse aus demselben Durchlauf:

Dieser Schritt reduziert Farben und ist damit nicht verlustfrei: Das Foto ging von 31.716 verschiedenen Farben auf 3.277 zurück, der Screenshot von 2.002 auf 1.314. Bei bereits optimierten Paletten-PNGs ist kaum noch etwas zu holen. Sie erneut durch ein Tool zu schicken, unseres eingeschlossen, lohnt sich meist nicht.

Sollte man einen Screenshot als JPG speichern?

In der Regel nicht. JPEG ist für weiche fotografische Details gebaut, Screenshots bestehen dagegen aus Flächenfarben mit scharfen Kanten um Text. Chrome speicherte unser JPG mit 4:2:0-Chroma-Subsampling, also mit halber Farbauflösung gegenüber der Helligkeit in beide Richtungen. Farbiger Text und dünne farbige Linien zeigen das zuerst. In unserem Ausschnitt mit 2-facher Vergrößerung war der Unterschied zum PNG bei Qualität 90 kaum zu erkennen, die Datei war aber trotzdem größer.

Verlangt eine Website unbedingt JPG, kam PNG zu JPG mit 80 % in unserem Durchlauf unter die PNG-Größe, mit 90 % nicht. Wo WebP angenommen wird, ist PNG zu WebP für Screenshots der bessere Tausch. Am kleinsten war ein Paletten-PNG. Einen Palettenmodus mit 256 Farben bieten wir nicht an; wenn Sie auch die letzten 50 kB loswerden wollen, nehmen Sie ein Tool wie pngquant oder Squoosh. Die Abwägungen zwischen diesen beiden Formaten beschreibt WebP vs. PNG.

Warum ist WebP oder AVIF größer als das Original?

Dafür gibt es zwei getrennte Gründe, und sie zeigten sich in zwei verschiedenen Tests.

Ein schon komprimiertes JPEG mit hoher Qualität umwandeln

WebP und AVIF sind bei gleicher sichtbarer Qualität oft kleiner als JPEG. Dieser Vergleich setzt aber eine saubere Quelle voraus. Geht man von einem JPEG aus, muss der neue Encoder die JPEG-Artefakte nachbilden, als wären sie Bilddetails.

Das JPEG mit 250 kB ging als WebP mit Qualität 90 von 250.382 auf 269.556 Bytes, 7,7 % mehr. Der Qualitätswert wiegt schwerer als das Format. Wenn Sie JPG zu WebP nutzen, ziehen Sie den Regler unter den Standardwert von 90 % und vergleichen Sie die Größen, oder probieren Sie JPG zu AVIF. Was AVIF mit feinen Texturen macht, beschreibt unsere ausführliche Analyse zu AVIF.

Winzige Bilder und fester Overhead

Jedes Format hat Fixkosten, etwa Header und bei verlustbehaftetem WebP mit Transparenz einen separat gespeicherten Alphakanal. Sie fallen stark ins Gewicht, wenn das ganze Bild nur 504 Bytes hat.

Verlustfreies WebP lag zwar 140 Bytes unter dem PNG, doch die meisten Varianten machten das Icon größer, auch beide AVIF-Einstellungen. Behalten Sie bei Icons und kleinen UI-Grafiken das PNG, oder nehmen Sie SVG, wenn Sie die Vektorvorlage haben. In unseren Tests sparten WebP und AVIF bei den Fotos Bytes, nicht beim Icon.

Kosten Hochskalieren oder Metadaten zusätzliche Bytes?

Vergrößern fügt Bytes hinzu, aber keine Details. Unser Vorschaubild mit 320 × 480 Pixeln hatte 28.034 Bytes. In Originalgröße mit Qualität 80 neu gespeichert, waren es 28.513 Bytes; zuerst auf 640 × 960 vergrößert, waren es 62.114 Bytes, 2,2-mal so viel für ein weicheres Bild. Unser Kompressor vergrößert nie, weil die Einstellung von 1.920 px eine Obergrenze ist. Ein Bildgrößen-Tool vergrößert dagegen, sobald Sie größere Werte eintippen. Prüfen Sie deshalb die Zielmaße im Bildgrößen-Tool, bevor Sie exportieren. Warum Hochskalieren keine Details zurückholt, erklärt Bilder skalieren ohne Qualitätsverlust.

Metadaten spielten in unserem Test eine kleine Rolle. Das Vorschaubild enthielt ein Display-P3-Farbprofil mit 480 Bytes und EXIF-Tags mit 258 Bytes, zusammen etwa 2,6 % seiner 28.290 Bytes. Unser Kompressor entfernt EXIF standardmäßig und behält es nur, wenn Sie „EXIF behalten“ einschalten. Kameradateien können größere Blöcke enthalten, etwa eingebettete Vorschaubilder. Bei kleinen Exporten aus Kamera oder Smartphone kann es daher mehr bringen, EXIF zu entfernen. Dabei verschwindet auch der GPS-Standort.

Was passiert, wenn man ein GIF umwandelt?

GIF ist alt, aber für eine kurze Animation mit wenigen Flächenfarben kompakt: Das Format speichert Palettenindizes und kann pro Frame nur den Teil ablegen, der sich geändert hat. Wir haben eine Animation mit 12 Frames und 240 × 240 Pixeln gezeichnet, in der ein Punkt über einen einfarbigen Hintergrund wandert:

An der Größe änderte keine dieser Varianten viel. Das Ergebnis gilt nur für eine kleine Animation mit Flächenfarben. Lange GIFs mit fotografischen Frames haben wir nicht getestet; dort kosten die Grenze von 256 Farben und das Dithering das GIF mehr. Für kurze Animationen mit Flächenfarben ist es vernünftig, beim GIF zu bleiben. Soll es kleiner werden, fangen Sie mit dem GIF-Kompressor an.

Was unsere Tools tun, wenn das Ergebnis größer ist

Die gesamte Verarbeitung oben läuft in Ihrem Browser; auf unserer Website wird das Bild nicht hochgeladen. So reagiert jedes Tool, wenn die Ausgabe wächst:

• Kompressor, Originalformat beibehalten: Er versucht es mit niedrigerer Qualität erneut, solange die Datei größer ist als die Quelle, und gibt Ihnen das Original zurück, wenn sie danach immer noch nicht kleiner ist.
• Kompressor, Format geändert: Sie bekommen die umgewandelte Datei, auch wenn sie größer ist. Die Ergebniskarte zeigt beide Größen, die Prozentangabe erscheint aber nur, wenn die Datei kleiner wurde. Vergleichen Sie also die beiden Zahlen.
• Konverter: Sie kodieren einmal mit dem Wert des Reglers (bei verlustbehafteten Ausgaben standardmäßig 90 %) und prüfen die Größe nicht. Beim Konvertieren geht es um das Format, die Größe kann also in beide Richtungen gehen.
• Zielgröße: Solange die Datei über Ihrem Ziel liegt, senkt jeder Durchlauf die Qualität und verkleinert Breite und Höhe um 5 %, sofern „Originalauflösung erzwingen“ nicht eingeschaltet ist. Nach 30 Durchläufen ist Schluss; ein nicht erreichtes Ziel markiert die Ergebniskarte.

Checkliste vor dem erneuten Komprimieren oder Konvertieren

1. Ist die Datei schon optimiert? Kommt sie aus einem CDN, einem CMS oder einem Tool wie TinyPNG, bringt ein zweiter Durchgang meist wenig; bei uns waren es 3,9 % und 0,4 %. Bei so kleinem Gewinn behalten Sie das Original.
2. Wandern Sie mit einem Foto ins PNG? Nur, wenn PNG verlangt wird. Unsere beiden JPEGs wuchsen um das 10,7- und 16,4-Fache.
3. Ist es ein Screenshot oder eine Grafik mit Flächenfarben? Bleiben Sie bei PNG oder nehmen Sie WebP. JPG mit 90 % war in unserem Test größer als das PNG.
4. Ist sie kleiner als ein paar kB? Lassen Sie Icons als PNG oder SVG. Die Header von WebP und AVIF können schwerer wiegen als die Pixel.
5. Sind die Pixelmaße gestiegen? Prüfen Sie die Ausgabegröße vor dem Speichern. Das Vergrößern hat die Bytes unseres Vorschaubilds mehr als verdoppelt.
6. Steht der Konverter auf 90 %? Versuchen Sie bei JPG zu WebP 75 bis 80 % und vergleichen Sie.
7. Brauchen Sie die Metadaten? Entfernen Sie EXIF bei kleinen öffentlichen Bildern; bei Fotos fürs Archiv behalten Sie es.

Wenn Sie nur eine kleinere Datei im selben Format wollen, starten Sie mit dem Kompressor und vergleichen Sie auf der Ergebniskarte die Größe vorher und nachher, bevor Sie herunterladen.