Bild komprimiert und größer? Die 3 echten Ursachen

Ihr Kompressor ist wahrscheinlich in Ordnung. Wenn die Bildkomprimierung nicht funktioniert und das Ergebnis genauso groß oder spürbar größer zurückkommt als das, was Sie hineingegeben haben, liegt das fast immer an einer von drei Ursachen. Ein defektes Werkzeug steht nicht auf der Liste.

Zuerst die häufigste. Jedes Werkzeug, das über das canvas-Element des Browsers komprimiert, verwirft den Farbtyp Ihres PNGs und kodiert jedes Pixel neu als 32-Bit-RGBA. Wir haben alle 83 Open-Graph-Karten dieser Website als PNG durch canvas.toBlob('image/png') in Chrome 151.0.0.0 geschickt. Jede einzelne der 83 Dateien kam größer zurück. Der Median des Zuwachses lag bei +76,6 %, der kleinste bei +35,6 %, der größte bei +237,2 %.

Die zweite Ursache: Ihr JPEG ist bereits komprimiert. Schicken Sie es fünfmal hintereinander mit Qualität 0,8 durch den Encoder, und die Dateigröße bewegt sich ab dem zweiten Durchgang nicht mehr, während jeder Durchgang das Bild weiter beschädigt.

Die dritte: Ihr PNG wurde bereits quantisiert. Es ist keine Farbredundanz mehr übrig, die ein zweiter Durchgang entfernen könnte.

Keine dieser Ursachen lässt sich beheben, indem Sie den Qualitätsregler weiter nach unten ziehen. Die Lösung ist ein anderes Format oder ein anderer Encoder. Genau dieselben 83 PNGs wurden als WebP mit Qualität 0,8 allesamt kleiner, im Median −94,2 %.

Wie diese Zahlen entstanden sind. Chrome 151.0.0.0, gesteuert über Playwright, macOS 26.5.2, Node v25.8.2, upng-js 2.1.0, ImageMagick. Der 83er-Satz umfasst jedes PNG im Verzeichnis public/og dieser Website, keine Stichprobe daraus. Vier zusätzliche kontrollierte Dateien mit 1200×630 und 800×600 decken die Fälle Foto, Grafik, Palette und JPEG getrennt ab.

1. Bildkomprimierung funktioniert nicht: die Dreißig-Sekunden-Diagnose

Suchen Sie Ihre Zeile und lesen Sie dann den Abschnitt, auf den sie zeigt.

Was Sie hineingegeben haben	Was Sie bekommen haben	Ursache	Weiterlesen
PNG-Screenshot oder Grafik	Größer als das Original	canvas hat es als 32-Bit-RGBA neu kodiert	Abschnitt 2
JPEG-Foto	Größer als das Original	Es wurde als PNG gespeichert	Abschnitt 2
JPEG-Foto	Kaum eine Veränderung	Bereits am Größen-Plateau	Abschnitt 3
PNG, das schon durch einen Kompressor lief	Keine Veränderung oder leicht größer	Kein Spielraum mehr vorhanden	Abschnitt 4
Beliebiges Bild	Kleiner, aber unscharf oder farbstichig	Generationsverlust oder ein entferntes ICC-Profil	Abschnitte 3 und 6

Die Zeilen schließen einander nicht aus. Ein JPEG-Foto, das in einen canvas-basierten PNG-Export fällt, trifft die ersten beiden gleichzeitig. So wird aus einer Datei mit 47.828 Bytes eine mit 809.415 Bytes.

Wenn Sie sich die Diagnose sparen und einfach eine kleinere Datei haben wollen: Unser Bildkomprimierer arbeitet mit einem quantisierenden PNG-Encoder statt mit einem canvas-Umweg und verwirft sein eigenes Ergebnis, sobald es nicht kleiner ist als das, was Sie hochgeladen haben.

2. Ursache eins: Das Browser-Canvas schreibt immer 32-Bit-RGBA

Was canvas.toBlob() wirklich mit Ihrem PNG macht

Ein canvas-Umweg komprimiert überhaupt nicht. Er dekodiert und kodiert danach neu, und alles, was kein Pixelwert ist, fällt dazwischen heraus.

Zeichnen Sie ein Bild auf ein Canvas, dekodiert der Browser es in einen flachen RGBA-Puffer: vier Bytes pro Pixel, keine Palette, keine Tricks mit der Bit-Tiefe, keine Metadaten. HTMLCanvasElement.toBlob() kodiert diesen Puffer anschließend von Grund auf neu. Die PNG-Spezifikation definiert sechs Farbtypen, und ein PNG-Encoder darf sich den günstigsten aussuchen, der das Bild abbildet. Chromes canvas-Encoder sucht nicht aus. Er schreibt immer color type 6.

Eingehender Farbtyp	Was canvas.toBlob('image/png') zurückgibt
RGB (color type 2)	RGBA (color type 6)
Palette (color type 3)	RGBA (color type 6)
JPEG (hat keinen PNG-Farbtyp)	RGBA (color type 6)

Sie können das direkt aus den Bytes ablesen. Byte 25 einer PNG-Datei ist die Bit-Tiefe, Byte 26 der Farbtyp, beide innerhalb des IHDR-Chunks:

xxd -s 24 -l 2 -p suspect.png
# 0806  ->  Bit-Tiefe 8, color type 6 (RGBA)

Alle drei oben genannten Eingabetypen ergaben depth=8 type=6. Ein Palettenbild mit 64 Farben speichert ein Byte pro Pixel plus eine kleine Tabelle; nach dem Umweg speichert es vier Bytes pro Pixel, und die Tabelle ist weg. Deflate holt einen Teil davon zurück, niemals alles.

Reproduzieren Sie es in Ihrem eigenen Browser mit diesem Konsolen-Snippet. Es wählt eine Datei aus, schickt sie durch das Canvas und gibt beide Größen sowie den Farbtyp aus:

const input = document.createElement('input');
input.type = 'file';
input.accept = 'image/png,image/jpeg';
input.onchange = async () => {
  const file = input.files[0];
  const bitmap = await createImageBitmap(file);
  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  canvas.getContext('2d').drawImage(bitmap, 0, 0);
  const blob = await new Promise((r) => canvas.toBlob(r, 'image/png'));
  const head = new Uint8Array(await blob.slice(0, 26).arrayBuffer());
  console.log(file.name, file.size, '->', blob.size);
  console.log('bit depth', head[24], 'color type', head[25]);
};
input.click();

Das Qualitätsargument von toBlob wird bei image/png ignoriert. PNG ist verlustfrei, es gibt also nichts, wogegen eine Qualitätszahl etwas eintauschen könnte. Ein Regler, der in einem canvas-basierten Werkzeug die PNG-Komprimierung zu steuern scheint, steuert nichts.

83 Dateien gemessen: Jedes komprimierte Bild kam größer zurück als das Original

Der vollständige Durchlauf, ohne Rosinenpickerei:

Messwert	Wert
Getestete Dateien	83 (jedes PNG in public/og, sowohl RGB- als auch Palettenfarbtypen)
Dateien, die wuchsen	83 / 83 (100 %)
Kleinste Zunahme	+35,6 %
Median der Zunahme	+76,6 %
Größte Zunahme	+237,2 %

Eine einzelne Datei, damit Sie die Größenordnung sehen: aes-decrypt.png ging von 505.516 B auf 898.014 B, eine Zunahme von +77,6 %. Dieselbe Datei als WebP mit Qualität 0,8 kodiert ergibt 27.188 B, −94,6 %.

Die Stichprobe hat Grenzen. Diese 83 Dateien sind Open-Graph-Karten: 1200×630, flache Hintergründe, große Schrift, eine Handvoll Markenfarben. Diese Art von Grafik beherrscht ein guter PNG-Encoder besonders gut, und genau deshalb schadet ihr ein canvas-Umweg so sehr. Das ist ein starkes Ergebnis für PNGs vom Typ Grafik; es ist keine Behauptung, dass jedes PNG der Welt bei einem canvas-Umweg wächst. Ein fotografisches PNG, das ohnehin schon als volles RGBA gespeichert war, hat sehr viel weniger zu verlieren.

Was es sehr wohl belegt: Wenn Ihr komprimiertes Bild größer ist als das Original und das Werkzeug in einem Browser-Tab läuft, dann ist der Encoder die erste Stelle, an der Sie nachsehen sollten, nicht Ihre Einstellungen.

Warum ein als PNG gespeichertes JPEG um das 16,9-Fache wächst

Das ist die dramatischste Zeile im Datensatz. Vier kontrollierte Dateien, alle vier durch denselben canvas-Pfad geschickt:

Datei	Charakter	Original	canvas-PNG	Änderung	JPEG q92	JPEG q80	WebP q80
og-a.png	Grafik, 2.351 Farben, RGB	306.302	607.481	+98,3 %	56.459	37.695	13.852
quantized.png	Palette mit 64 Farben	59.843	184.856	+208,9 %	78.388	44.442	16.046
photo.png	Foto, 479.373 Farben	498.639	867.763	+74,0 %	77.321	45.050	24.068
photo.jpg	JPEG q82	47.828	809.415	+1.592 % (16,9×)	58.762 (+22,9 %)	47.152	23.862

Diese letzte Zeile heißt: 47.828 Bytes hinein, 809.415 Bytes heraus.

Der Mechanismus erklärt eine ganze Familie von Meldungen der Art „Komprimierung hat es größer gemacht“. JPEG ist ein verlustbehafteter Codec im Frequenzbereich: Er transformiert 8×8-Blöcke in DCT-Koeffizienten, quantisiert sie aggressiv und speichert, was übrig bleibt. PNG ist ein verlustfreier Codec im Ortsbereich: Er sagt jedes Pixel aus seinen Nachbarn voraus und komprimiert die Restwerte mit Deflate. Dekodieren Sie ein JPEG, bekommen Sie Pixel, die jedes Artefakt des Quantisierers mit sich tragen: Ringing an Kanten, Blockbildung in weichen Verläufen, feines Rauschen dort, wo das Original keines hatte.

Speichern Sie diese Pixel als PNG, verlangen Sie von einem verlustfreien Codec, die Artefakte perfekt abzubilden. Er tut es. Ausgerechnet das Rauschen, das JPEG erzeugt hat, um die Datei klein zu machen, bläht jetzt das PNG auf, denn Rauschen ist genau das, was ein prädiktiver verlustfreier Encoder nicht komprimieren kann.

Überall dort, wo ein „Als PNG speichern“ als Standard vor einem Foto sitzt, passiert genau das: Screenshot-Werkzeuge, Design-Exporte, Chat-Clients, manche Upload-Widgets.

Dieselben Pixel, Faktor 3,46 auseinander, beide verlustfrei

Der canvas-Encoder ist außerdem messbar schwach. Nehmen Sie den Pixelpuffer von og-a.png und kodieren Sie ihn auf zwei Arten, beide vollständig verlustfrei:

Encoder	Ausgabe	Farbtyp
Chrome canvas toBlob('image/png')	607.481 B	RGBA (erzwungenes Upsampling)
upng-js encode(..., cnum=0)	175.491 B	RGB (ursprünglicher Farbtyp erhalten)

3,46×, bei identischen Pixeln. Wir haben die Verlustfreiheit überprüft statt sie anzunehmen: Dekodiert man die upng-js-Ausgabe bei cnum=0, ergibt sich ein Puffer, der Byte für Byte mit dem eingegebenen RGBA-Puffer übereinstimmt. Der Faktor 3,46 kostet also keine Qualität.

Das beantwortet eine Frage, die viele stellen: Warum liefern zwei Online-Kompressoren, beide kostenlos, beide mit derselben Beschreibung, Ergebnisse, die nicht im Entferntesten vergleichbar sind? Weil „im Browser komprimieren“ zwei völlig verschiedene Implementierungen beschreibt. Die eine reicht die Pixel an canvas.toBlob weiter und liefert aus, was zurückkommt. Die andere bringt einen echten PNG-Encoder mit und kontrolliert den Farbtyp. Gleiche Eingabe, gleicher Browser, Faktor 3,46 Unterschied.

3. Ursache zwei: Ihr JPEG hat nichts mehr herzugeben

Fünf Runden Neukomprimierung, und die Größe bewegt sich nicht mehr

Nehmen Sie photo.jpg, das bereits mit Qualität 82 gespeichert wurde, und komprimieren Sie es fünfmal hintereinander mit Qualität 0,8 neu, wobei jede Generation die nächste speist:

Generation	Bytes	ggü. vorheriger
0 (Original, q82)	47.828	—
1	47.152	−1,4 %
2	47.164	+0,0 %
3	47.156	−0,0 %
4	47.156	0,0 %
5	47.156	0,0 %

Der erste Durchgang bringt Ihnen 1,4 %. Ab Generation 2 sitzt die Dateigröße in einem Band von ±12 Bytes fest, und die Generationen 4 und 5 sind in der Größe bitgenau identisch mit Generation 3.

So sieht „Komprimierung funktioniert nicht“ aus, wenn die Eingabe ein JPEG ist. Das Werkzeug lief. Der Encoder lief. Es war schlicht nichts mehr zu entfernen, weil die Quantisierungstabellen bei Qualität 80 ungefähr jene Koeffizienten bereits auf null gesetzt hatten, die Qualität 82 behalten hatte. Ist ein Koeffizient einmal weg, kann er nicht noch einmal entfernt werden.

Sie können lokal zusehen, wie es passiert:

cp photo.jpg gen0.jpg
for i in 1 2 3 4 5; do
  magick "gen$((i-1)).jpg" -quality 80 "gen$i.jpg"
done
stat -f%z gen0.jpg gen1.jpg gen2.jpg gen3.jpg gen4.jpg gen5.jpg

Unter Linux nehmen Sie stattdessen stat -c%s. Die genauen Byte-Zahlen hängen davon ab, gegen welchen Encoder Ihr ImageMagick-Build gelinkt ist. Erwarten Sie also nicht, dass sich die Tabelle oben Ziffer für Ziffer reproduzieren lässt, es geht um die Form der Kurve. Ein spürbarer Sprung, danach eine flache Linie.

Die Qualitätszahl hochzudrehen ist keine Komprimierung

Sehen Sie sich die Zeile photo.jpg in Abschnitt 2 noch einmal an. Das mit Qualität 82 gespeicherte Original mit Qualität 92 neu zu komprimieren ergab 58.762 Bytes: +22,9 %.

Das überrascht alle, die den Qualitätsparameter für einen Regler von „klein“ nach „groß“ halten, den man beliebig setzen darf. Er ist kein absolutes Qualitätsziel. Er wählt eine Quantisierungstabelle aus, und ein dekodiertes Bild durch eine feinere Tabelle zu schicken als jene, die es erzeugt hat, speichert die vorhandenen Artefakte präziser und legt obendrein eine frische Runde Verlust darauf. Größere Datei, schlechteres Bild, beides gleichzeitig.

Die Regel, die daraus folgt: Komprimieren Sie ein JPEG niemals mit einer höheren Qualitätseinstellung neu, als es beim Speichern hatte. Wenn Sie nicht wissen, welche das war, komprimieren Sie es gar nicht erst neu. Gehen Sie zurück zur Quelle.

Generationsverlust: der JPEG-Qualitätsverlust, den Sie nicht sehen

Die Plateau-Tabelle hat eine Falle. Die Größe hörte nach Generation 2 auf sich zu ändern, das Bild änderte sich weiter. Jeder Durchgang dekodiert zu Pixeln, transformiert erneut und quantisiert erneut. Koeffizienten, die in einer Generation knapp an einer Grenze überlebt haben, werden in der nächsten darüber geschoben.

Der Schaden zeigt sich nicht dort, wo Sie ihn suchen. In Miniaturansicht sind Generation 5 und Generation 1 nicht zu unterscheiden. Zoomen Sie auf 100 % und prüfen Sie die Stellen, an denen JPEG immer zuerst scheitert: harte Kanten vor flachen Hintergründen, Text und weiche Verläufe, in denen Blockbildung als sichtbare 8×8-Kacheln auftritt. In einer Build-Pipeline, die bei jedem Deploy neu komprimiert, sammelt sich das über Monate hinweg still an.

Wir haben hier Dateigrößen gemessen, keine wahrgenommene Qualität. Deshalb nennen wir Ihnen für die fünf Generationen auch keinen PSNR- oder SSIM-Wert. Wir haben keinen erhoben. Was allein die Größendaten belegen, reicht ohnehin: Ab Generation 2 fallen nur noch Kosten auf der Qualitätsseite an, und der Nutzen ist null.

Farbverschiebungen sind ein eigenes Problem mit demselben Auslöser. Canvas trägt keine Metadaten, also verwirft ein toBlob-Umweg den EXIF-Block und mit ihm das ICC-Profil. Ein Bild, das mit Display P3 oder Adobe RGB ausgezeichnet hineingeht, kommt ohne Auszeichnung heraus, und Betrachter interpretieren es dann als sRGB. Die Pixelwerte haben sich nicht bewegt. Die Anweisung, wie sie zu lesen sind, schon.

4. Ursache drei: PNG wird nicht kleiner, weil es bereits quantisiert war

Wenn Ihr PNG schon einmal durch einen Kompressor gelaufen ist, hat der zweite Durchgang nichts mehr, womit er arbeiten könnte. Das ist die Zeile quantized.png, eine 59.843 Bytes große Datei, die bereits auf eine Palette mit 64 Farben reduziert war, hier über drei getrennte Wege geschickt:

Weg	Ergebnis	ggü. Original
Verlustfreie Neukodierung (upng cnum=0)	61.377	+2,6 %
Quantisierung auf 256 Farben	61.366	+2,5 %
Quantisierung auf 64 Farben	61.366	+2,5 %

Jeder Weg endete größer als das Original. Nicht viel größer, aber größer, und das schließt die Quantisierung einer Datei auf 64 Farben ein, die bereits 64 Farben hatte.

PNG-Komprimierung funktioniert, indem sie Redundanz entfernt: wiederholte Farben, vorhersagbare Nachbarn, eine kleine Palette. Ein früherer Durchgang hat all das bereits eingesammelt. Was übrig bleibt, ist nahezu inkompressibel, und die winzige Zunahme ist der Overhead des Encoders selbst: eine etwas andere Palettenreihenfolge, andere Filterentscheidungen pro Bildzeile, ein minimal weniger glückliches Deflate.

Die praktische Konsequenz: „0 % gespart“ bei einem bereits optimierten PNG ist das richtige Ergebnis, kein Fehlschlag. Ein Werkzeug, das eine kleine Zunahme meldet und dann Ihre Originaldatei behält, verhält sich korrekt. Ein Werkzeug, das Ihnen die größere Datei trotzdem aushändigt, verhält sich falsch.

5. Bei PNG spart die Quantisierung, nicht das Neukodieren

Verlustfreie Neukodierung gegen 256 Farben gegen 64 Farben

Drei Dateien, drei Strategien, gemessen:

Datei	Original	Verlustfrei (cnum=0)	256 Farben	64 Farben
og-a.png	306.302	175.491 (−42,7 %)	110.772 (−63,8 %)	76.230 (−75,1 %)
photo.png	498.639	587.863 (+17,9 %)	109.284 (−78,1 %)	61.397 (−87,7 %)
quantized.png	59.843	61.377 (+2,6 %)	61.366 (+2,5 %)	61.366 (+2,5 %)

Verlustfreies Neukodieren ist das schwächste der drei Werkzeuge. Es sparte 42,7 % bei der Grafik, legte beim Foto 17,9 % zu und bei der bereits quantisierten Datei 2,6 %. Fotografische Inhalte bezwingen selbst einen kompetenten verlustfreien PNG-Encoder, weil es keine Palette zu finden gibt und benachbarte Pixel einander schlecht vorhersagen.

In der Quantisierung steckt die echte Reduktion, und der Abstand ist deutlich: 63,8 % gegenüber 42,7 % bei derselben Grafik mit 256 Farben, 75,1 % bei 64. Auf der Kommandozeile:

magick logo.png -colors 64 PNG8:logo-64.png
magick logo.png -colors 256 PNG8:logo-256.png

Das Präfix PNG8: erzwingt ein Paletten-PNG. Ohne es reduziert ImageMagick unter Umständen die Farben und schreibt trotzdem eine Truecolor-Datei, was den größten Teil des Gewinns wieder wegwirft.

Wann eine Palette sicher ist und wann Sie Banding bekommen

Quantisierung ist verlustbehaftet. Sie bildet jedes Pixel auf den nächstgelegenen Eintrag einer begrenzten Palette ab. Die Frage ist also, ob Ihr Inhalt genug unterschiedliche Farben hat, dass das sichtbar wird.

Sicher: Icons, Logos, UI-Screenshots, flache Illustrationen, Diagramme, alles mit großen Flächen gleichmäßiger Farbe und harten Kanten. Solche Bilder enthalten typischerweise höchstens ein paar Hundert verschiedene Farben, eine Palette mit 256 Einträgen ist damit praktisch kostenlos, und selbst 64 überstehen sie oft.

Riskant: Fotografien, weiche Verläufe, sanfte Schlagschatten und halbtransparente Überlagerungen. Einen Verlauf auf 64 Stufen zu reduzieren erzeugt sichtbare Streifen, und Dithering tauscht diese Streifen gegen Rauschen ein, das Ihnen anschließend einen Teil der Dateigröße zurückkostet. Teiltransparenz über einem Verlauf ist der schwierigste Fall überhaupt.

Transparenz verdient eine eigene Prüfung, denn wie viel davon überlebt, hängt am Encoder und nicht an der Quantisierung selbst. ImageMagicks PNG8: schreibt binäre Transparenz, ein Pixel ist also entweder vollständig deckend oder vollständig durchsichtig, und eine weich kantengeglättete Kante kommt hart zurück. Ein spezialisierter PNG-Quantisierer behält den vollen Alphakanal und damit die weiche Kante. Hat Ihr Asset einen Schlagschatten oder ausgefranste Kanten, vergleichen Sie beide, bevor Sie sich festlegen.

Prüfen Sie das Ergebnis bei 100 %, nicht in einer Miniaturansicht. Banding ist genau das Artefakt, das eine verkleinerte Vorschau zuverlässig verbirgt.

6. Die Lösung: Bilder per Formatwechsel verkleinern statt neu komprimieren

Eine Entscheidungstabelle für Formate

Inhalt	Verwenden Sie	Warum
Fotografien	WebP, oder JPEG für maximale Kompatibilität	Verlustbehaftete Frequenzkodierung ist genau das, was Fotos brauchen
Screenshots, UI-Grafiken	Quantisiertes PNG, oder WebP	Flache Farben, harte Kanten, kleine Paletten
Icons und Logos	SVG, wenn Sie den Vektor haben, sonst quantisiertes PNG	Vektoren haben kein Auflösungsproblem
Alles mit Transparenz	WebP oder PNG	Beide tragen einen vollen Alphakanal
Animation	WebP	Ein Format statt eines GIFs
Pixelgenaue Archivierung	PNG, verlustfrei	Der einzige Fall, in dem Verlustfreiheit die Anforderung ist

Das ist bewusst die Kurzfassung. Kodiereffizienz und Browser-Unterstützung der modernen Formate haben einen eigenen Artikel: WebP vs. AVIF vs. JPEG.

Was WebP mit denselben 83 Dateien gemacht hat

Derselbe Satz von 83 Dateien, der über canvas-PNG in 100 % der Fälle wuchs, stattdessen als WebP mit Qualität 0,8 konvertiert: 83 von 83 wurden kleiner, im Median −94,2 %. Die einzelne Datei von vorhin, aes-decrypt.png, ging von 505.516 B auf 27.188 B, −94,6 %.

Die kontrollierten Dateien bestätigen das. og-a.png: 306.302 als PNG, 13.852 als WebP q80. photo.png: 498.639 als PNG, 24.068 als WebP q80. photo.jpg: 47.828 als JPEG, 23.862 als WebP q80.

Eine Einschränkung zum letzten Vergleich. WebP mit Qualität 0,8 ist verlustbehaftet, tritt also nicht zu gleichen Bedingungen gegen PNG an, und ein vorhandenes JPEG nach WebP umzukodieren kostet Sie trotzdem eine Generation. Vergleichen Sie mit dem, was Sie gerade ausliefern wollten, nicht mit einem hypothetisch perfekten Original.

Wann Sie das PNG trotzdem behalten sollten

Verlustfreiheit ist manchmal die Anforderung und nicht eine Vorliebe. Behalten Sie PNG für Assets, die zurück in eine Design-Pipeline gehen und dort erneut bearbeitet werden, für Screenshots in Pixelvergleichstests, für UI-Ausschnitte, bei denen eine einzige verschobene Farbe einen visuellen Diff zerlegt, und für alles, was später noch zusammengesetzt wird und wo sich Quantisierungsartefakte aufaddieren würden. Fahren Sie in diesen Fällen einen richtigen quantisierenden Encoder, wenn der Inhalt es erlaubt, und akzeptieren Sie die Dateigröße, wenn er es nicht tut.

Noch eine Art von „größer“, die nichts mit Komprimierung zu tun hat

Wenn Sie Bilder als Data-URIs einbetten, ist die Größe in Ihrem CSS oder HTML nicht die Größe auf der Festplatte. Base64 kodiert jeweils 3 Bytes als 4 Zeichen, dazu kommt Padding, der Text ist also rechnerisch +33 % größer als die Bytes, die er transportiert, und zwar vor jeder Transportkomprimierung. Ein perfekt optimiertes Bild wird in dem Moment um ein Drittel größer, in dem Sie es einbetten. Wann dieser Kompromiss lohnt, behandelt unser Leitfaden zum Data-URI-Inlining.

7. In der Praxis: Browser, Kommandozeile, Build-Pipeline

Im Browser

Bei einem browserbasierten Werkzeug lautet die Frage, ob PNG durch das Canvas läuft. In unserem Bildkomprimierer tut es das nicht. Er quantisiert PNG-Eingaben auf eine Farbpalette und schreibt sie als echtes PNG mit intaktem Alphakanal zurück, sodass Transparenz und weiche Kanten überleben; der Qualitätsregler steuert eine Palettengröße statt eines toBlob-Arguments, das PNG ohnehin ignorieren würde. Qualität 100 entspricht einer verlustfreien Neukodierung. JPEG und WebP laufen sehr wohl durch das Canvas, wo der Qualitätsparameter echt ist und tut, was Sie erwarten.

Ein Verhalten sollten Sie kennen, weil es wie ein Fehler aussieht und keiner ist: Ist das komprimierte Ergebnis nicht kleiner als die Datei, die Sie hochgeladen haben, wirft das Werkzeug seine eigene Ausgabe weg und behält Ihre Originalbytes. Bei einem bereits optimierten PNG sehen Sie dann „0 % gespart“. Das ist Abschnitt 4 in Aktion, so gewollt.

Die Verarbeitung läuft lokal, Ihre Datei verlässt den Browser also nie.

Auf der Kommandozeile

cwebp kommt mit libwebp und ist der schnellste Weg, um zu prüfen, ob ein Formatwechsel Ihr Problem löst:

# Verlustbehaftetes WebP, Qualität 0-100
cwebp -q 80 photo.png -o photo.webp

# Verlustfreies WebP, Kompressionsaufwand 0-9
cwebp -z 9 logo.png -o logo.webp

ImageMagick 7 deckt die Fälle Konvertierung und Quantisierung ab:

# PNG nach JPEG mit gewählter Qualität
magick photo.png -quality 80 photo.jpg

# Auf ein Paletten-PNG mit 64 Farben quantisieren
magick logo.png -colors 64 PNG8:logo-64.png

# EXIF und andere Metadaten entfernen
magick photo.jpg -strip photo-clean.jpg

Unter macOS ist sips bereits installiert und braucht keine Abhängigkeiten:

# Nach JPEG konvertieren; formatOptions nimmt 0-100 oder low/normal/high/best
sips -s format jpeg -s formatOptions 80 photo.png --out photo.jpg

# So skalieren, dass die längste Kante 1200 px misst, Seitenverhältnis bleibt erhalten
sips -Z 1200 photo.jpg --out photo-1200.jpg

# Die Abmessungen wieder auslesen
sips -g pixelWidth -g pixelHeight photo-1200.jpg

Skalieren Sie, bevor Sie komprimieren. Encoder arbeiten auf Pixeln, und das billigste Pixel ist das, welches gar nicht existiert.

In einer Build-Pipeline

Sobald das automatisiert statt manuell abläuft, verschiebt sich die Entscheidung dahin, wo die Arbeit stattfindet und welche Bibliothek sie erledigt. Diesen Vergleich behandelt Bildkomprimierung im Browser gegenüber Node.js. Die eine Regel, die aus diesem Artikel mitkommt: Komprimieren Sie bei jedem Build aus der Originaldatei, niemals aus der Ausgabe des vorherigen Builds. Genau so läuft eine Pipeline die Generationsverlust-Kurve hinunter, während die Dateigrößen völlig stabil aussehen.

8. Fünf Überzeugungen, die die Messungen nicht stützen

„Zweimal komprimieren macht es kleiner.“ Generation 1 brachte 1,4 %. Die Generationen 2 bis 5 blieben innerhalb von ±12 Bytes, während das Bild weiter zerfiel. Der zweite Durchgang ist reine Kosten.

„PNG ist verlustfrei, also ist es das bessere Format.“ Verlustfreiheit ist eine Eigenschaft, keine Tugend. Unser Testfoto hat 498.639 Bytes als PNG und 24.068 als WebP q80. Eine Fotografie bitgenau zu erhalten, wenn sie ohnehin nur auf einem Bildschirm betrachtet wird, bringt nichts und kostet den größten Teil der Datei.

„Qualität 100 ist die sichere Wahl.“ Ein JPEG mit Qualität 82 mit Qualität 92 neu zu komprimieren ergab +22,9 % und ein schlechteres Bild. Oberhalb der ursprünglichen Qualitätseinstellung bedeutet die Zahl nicht mehr „sicherer“, sondern „größer“.

„Die Datei ist groß, weil die Auflösung hoch ist.“ Auflösung spielt eine Rolle, aber bei gleicher Auflösung spielt das Format eine größere. og-a.png ist so oder so 1200×630: 607.481 Bytes als canvas-PNG, 13.852 Bytes als WebP q80. Identische Pixelzahl.

„Online-Kompressoren sind alle gleich.“ Gleiche Pixel, gleicher Browser, beide verlustfrei: 607.481 Bytes aus dem Canvas, 175.491 aus upng-js. Ein Abstand von Faktor 3,46 zwischen zwei Werkzeugen, die sich selbst identisch beschreiben.

9. FAQ

Warum ist mein komprimiertes Bild größer als das Original?

Weil das Werkzeug es neu kodiert statt komprimiert hat. Die Ausgabe des Browser-Canvas ist immer ein 32-Bit-RGBA-PNG, das Paletten verwirft und vier Bytes pro Pixel speichert. In unserem Test mit 83 echten PNGs wuchsen alle 83, im Median um +76,6 %. Konvertieren Sie stattdessen nach WebP oder JPEG.

Warum wird mein PNG beim Komprimieren nicht kleiner?

PNG ist verlustfrei, ein Qualitätsregler hat also nichts, was er eintauschen könnte. Echte Reduktion kommt daher, die Farbanzahl zu senken, und wenn die Datei bereits quantisiert war, ist nichts mehr zu senken. Unser Test-PNG mit 64 Farben kam bei +2,5 % heraus, nachdem es ein zweites Mal auf 64 Farben quantisiert wurde.

Verliert ein JPEG Qualität, wenn man es zweimal komprimiert?

Ja, und Sie bekommen fast nichts dafür. Fünf Runden mit Qualität 0,8: 47.828 Bytes fielen im ersten Durchgang auf 47.152 und blieben in den vier folgenden innerhalb von 12 Bytes eingesperrt. Die Größe bewegte sich nicht mehr, während jeder Durchgang das Bild erneut quantisierte. Bewahren Sie Ihre Originale auf.

PNG oder JPEG, womit wird eine Datei kleiner?

Bei Fotografien ausnahmslos JPEG oder WebP. Unser Testfoto maß 498.639 Bytes als PNG, 45.050 als JPEG q80 und 24.068 als WebP q80. Halten Sie PNG für flache Grafiken, scharfen Text und Transparenz zurück, wo eine kleine Palette die Komprimierungsarbeit übernimmt.

Warum ist mein Bild nach dem Komprimieren unscharf?

Dafür gibt es zwei Ursachen. Verlustbehaftete Encoder erzeugen bei niedrigen Qualitätseinstellungen sichtbare Blockbildung an Kanten und Text. Wiederholte Durchgänge fügen Generationsverlust hinzu, selbst wenn die Dateigröße sich nicht mehr ändert. Haben sich eher die Farben verschoben als die Schärfe verändert, hat der canvas-Umweg Ihr ICC-Profil verworfen, denn Canvas trägt überhaupt keine Metadaten.

Kann ich ein Bild ohne Qualitätsverlust komprimieren?

Ja, aber erwarten Sie deutlich weniger. Verlustfreies Neukodieren schreibt lediglich identische Pixel effizienter: 306.302 auf 175.491 Bytes bei unserer Grafik, nach dem Dekodieren Byte für Byte als identisch verifiziert. Derselbe Ansatz ging bei einem Foto in die falsche Richtung, +17,9 %. Für echte Einsparungen ohne sichtbaren Verlust nehmen Sie WebP mit Qualität 80.

Warum ist mein PNG so groß, obwohl es nur ein Screenshot ist?

Bildschirmaufnahmen werden als volles RGBA-PNG gespeichert, vier Bytes pro Pixel vor der Komprimierung, und ein Retina-Display verdoppelt die Pixelzahl in jeder Dimension. Flache Inhalte sprechen gut auf Palettenreduktion an: Unsere Open-Graph-Kartengrafik verlor 63,8 % bei 256 Farben und 75,1 % bei 64.

Bringt Verkleinern mehr als Komprimieren?

Meistens ja, und beides verstärkt sich gegenseitig. Beide Abmessungen zu halbieren entfernt drei Viertel der Pixel, bevor der Encoder überhaupt anfängt, und die Dateigröße folgt grob der Pixelzahl. Skalieren Sie zuerst auf die Abmessungen, die Sie tatsächlich anzeigen, und komprimieren Sie dann einmal. Eine Kameradatei in voller Auflösung, die in einen Thumbnail-Platz fällt, verschwendet beide Durchgänge.