Client-seitige Bildkomprimierung: Was wirklich im Browser passiert

Ziehen Sie ein Foto in einen browserbasierten Kompressor, und im Normalfall verlässt nichts Ihr Gerät. Die Seite liest die Datei, dekodiert sie, zeichnet sie, kodiert sie erneut und gibt einen Blob zurück. Das ist der ganze Trick.

Der strukturelle Teil daran ist mehr wert als jede Datenschutzerklärung. Bei einem Scan eines Reisepasses oder einem Produktfoto vor dem Launch ist "die Bytes haben dieses Notebook nie verlassen" etwas, das Sie in den DevTools in zehn Sekunden nachprüfen können. "Wir löschen Uploads nach 24 Stunden" können Sie nur glauben.

Es folgt, was der Browser tatsächlich tut, welche Formate er sich weigert zu erzeugen, und ab wann Sie besser einen Server dazwischenschalten.

Dekodieren, zeichnen, neu kodieren

Ob Canvas oder WebCodecs, die Form ist dieselbe:

1. Datei lesen. Die File-API gibt JavaScript einen Byte-Stream, ohne Netzwerk.
2. Dekodieren. Aus dem komprimierten Bild werden rohe Pixel, RGBA, vier Bytes pro Stück.
3. Skalieren, falls überhaupt. Nur an dieser Stelle geht das.
4. Neu kodieren. Die Pixel mit einer Zielqualität wieder herausschreiben.
5. Einen Blob zurückgeben. Die Seite kann ihn zum Download anbieten oder in einer Vorschau zeigen.

Schritt zwei ist der schmerzhafte. Ein Foto mit 5472 mal 3648 Pixeln aus einer Mittelklassekamera hat rund 20 Megapixel, dekodiert belegt es also etwa 80 MB Speicher, ganz gleich ob das JPEG auf der Platte 5 MB gross war. Das Kompressionsverhältnis, das Sie eben noch bewundert haben, existiert nur auf der Platte.

Canvas, das Arbeitspferd

Der Canvas-Weg funktioniert in jedem Browser des letzten Jahrzehnts und ist etwa acht Zeilen lang:

async function compressJpeg(file, quality = 0.8) {
  const bitmap = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
  canvas.getContext('2d').drawImage(bitmap, 0, 0);
  const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality });
  bitmap.close();
  return blob;
}

quality läuft von 0 bis 1 und steuert bei JPEG und WebP die Quantisierungstabellen des Encoders. Bei verlustfreien Formaten wird der Wert schlicht ignoriert¹, und das ist das Erste, was bei PNG falsch verstanden wird.

OffscreenCanvas erlaubt es, das alles in einem Web Worker laufen zu lassen, sodass ein 40-MB-Bild die Oberfläche nicht einfriert. Safari war die letzte Engine, die es ausgeliefert hat, in 16.4², und 2D ist der Teil, der gelandet ist.

Die Formate, die er nicht kodiert, und wie leise er ablehnt

Jetzt das Verhalten, das Leute einen Nachmittag kostet.

Übergeben Sie einen MIME-Typ, den der Browser nicht kodieren kann, wirft toBlob keine Exception und liefert auch kein null. Der spezifizierte Rückfall ist, stattdessen PNG zu kodieren¹. Sie bekommen einen Blob, Ihr Success-Handler läuft, Ihr Download klappt, und die Datei ist ein PNG mit dem Namen, den Sie ihr gegeben haben.

Gemessen habe ich das in Chromium 147 und Firefox 148 im Headless-Modus am 19. August 2026, gesteuert über Playwright 1.59.1. Zwei Zeilen reproduzieren es in dem Browser, den Sie gerade offen haben:

const blob = await new Promise((r) => canvas.toBlob(r, 'image/avif', 0.8));
console.log(blob.type); // "image/png" in Chromium 147 und Firefox 148

Bei einem Foto ist das schlimmer als ein Fehler, denn ein PNG eines dekodierten Fotos ist regelmässig grösser als das JPEG, das Sie hineingegeben haben. Der Kompressor meldet Erfolg, und die Datei wächst.

Format	Canvas kann es kodieren	Anmerkung
PNG	Ja	Verlustfrei, quality tut also nichts
JPEG	Ja	Nativer Codec, auf den meisten Geräten hardwarebeschleunigt
WebP	Ja	25 bis 34 Prozent kleiner als JPEG bei gleichem SSIM4
AVIF	Nein, liefert PNG	Braucht WebCodecs plus eigenes Muxing oder einen WASM-Encoder
JPEG XL	Nein, liefert PNG	Ebenso

Die pragmatische Vorgabe für einen Browser-Kompressor im Jahr 2026 ist damit WebP mit quality: 0.85. Es ist das beste Format, das die Plattform tatsächlich herausgibt.

WebCodecs hat keinen Bild-Encoder

Diesen Punkt drehen die meisten Texte um, auch die frühere Fassung dieses Artikels. WebCodecs ist kein schnellerer Weg zu AVIF-Standbildern. Es ist eine Video-API.

ImageDecoder gibt es, und er ist wirklich nützlich, um Einzelbilder aus einem animierten Bild zu holen. Einen ImageEncoder gibt es nicht. Ich habe in beiden Engines danach gesucht, und in beiden ist er undefined.

Möglich ist, mit VideoEncoder einen einzelnen AV1-Keyframe zu kodieren, was Chromium wie Firefox für av01.0.04M.08 als unterstützt melden, und anschliessend selbst einen AVIF-Container um den Chunk zu bauen. Das ist ein echtes Verfahren, und es ist eher ein Container-Format-Projekt als eine Kompressionseinstellung. VideoEncoder ist auf sichere Kontexte beschränkt³, ist auf einer Seite über einfaches HTTP also undefined, was eine verwirrende Art ist, diese Anforderung zu entdecken. Safari hat die Video-Hälfte von WebCodecs seit 16.4².

Wer AVIF im Browser will, ohne einen Muxer zu schreiben, liefert einen WebAssembly-Encoder aus. Squoosh ist genau diesen Weg gegangen und bündelt Codec-Builds, um an Encoder zu kommen, die die Plattform nicht bereitstellt⁶. Es funktioniert. Die Bundles sind mehrere Megabyte gross, und Ihre Nutzer zahlen das beim ersten Laden.

PNG ist ein ganz anderes Problem

Es gibt keinen Qualitätsregler, weil nichts weggeworfen wird. Die Grösse ergibt sich aus der Deflate-Stufe und vor allem aus dem Inhalt: Flächige Farbe komprimiert hervorragend, fotografisches Korn praktisch gar nicht.

Drei Dinge verkleinern ein PNG wirklich.

Farbtiefe reduzieren. Ein Bild mit 256 Farben gehört in eine 8-Bit-Palette, nicht in 24-Bit-Truecolor. Im Browser heisst das ein WebAssembly-Build von etwas wie pngquant, denn Canvas übernimmt das nicht.

Format wechseln. Ein Foto, das als PNG ankam, liegt im falschen Container, und WebP mit 0.85 wird bei ähnlicher sichtbarer Qualität drastisch kleiner. Dafür ist unser Bildformat-Konverter da.

Skalieren. Grob, und wirksamer als die beiden anderen.

Speicher, an der Stelle, an der es bricht

Ein Bild nach dem anderen ist auf jeder Maschine dieses Jahrzehnts unproblematisch. Bei Stapeln sterben Tabs.

Dreissig Urlaubsfotos mit je 20 Megapixeln sind 2,4 GB dekodierte Pixel, wenn Sie alle dreissig Dekodierungen gleichzeitig anstossen, und mobiles Safari beendet den Tab lange vorher. Die Abhilfe ist unspektakulär: seriell arbeiten und auf jedem ImageBitmap close() aufrufen, bevor das nächste beginnt, was die dahinterliegenden Grafikressourcen freigibt⁵. Dieser ausgelassene Aufruf ist die häufigste Ursache für Out-of-Memory-Abstürze in Bild-Tools im Browser.

Zwei gleichzeitig ist eine vernünftige Obergrenze, wenn mehr als ein Kern beschäftigt sein soll.

Wo ein Server weiterhin gewinnt

Produktive Stapelverarbeitung. Die Asset-Pipeline eines Marketing-Teams durch einen Browser-Tab zu schicken funktioniert, bis jemand den Tab schliesst. libvips auf einem Server ist schneller, besser konfigurierbar und braucht keinen anwesenden Menschen.

AVIF und JPEG XL in Menge. Siehe oben: Die Plattform kodiert beides nicht, und der WASM-Weg kostet Bundle-Grösse und Kodierzeit.

Encoder-spezifisches Tuning. Chroma-Subsampling, mozjpeg-Quantisierungstabellen, Paletten-Quantisierung. Das alles braucht ein echtes Encoder-Binary.

Farbverbindliche Arbeit. Ein Canvas hat einen eigenen Farbraum, ein von der Kamera eingebettetes Wide-Gamut-ICC-Profil überlebt den Umweg also nicht. Für Druck oder medizinische Bildgebung ist diese Verschiebung nicht hinnehmbar, und die Komprimierung gehört dorthin, wo das Profil erhalten bleibt.

Die Datenschutz-Behauptung prüfen statt glauben

Wenn die Komprimierung auf einem Canvas passiert, haben die Pixeldaten keinen Weg zu einem Server. Das ist eine Eigenschaft des Codepfads, kein Versprechen, und es gilt für alles Sensible, das Sie in so ein Tool ziehen: ein abfotografiertes Dokument, ein Screenshot eines privaten Chats, Entwürfe unter NDA.

Nachprüfen lässt sich das in unter einer Minute. DevTools öffnen, Tab Netzwerk, ein Bild komprimieren und auf eine Anfrage achten, die die Datei trägt. Bei einem Upload-Tool sehen Sie sie sofort. Bei einem Canvas-Tool gibt es nichts zu sehen. Dieser Test trägt weit über Bild-Tools hinaus, und darum geht es im Leitfaden zur Online-Privatsphäre grösstenteils.

Welche API wofür

• Skalieren und JPEG oder WebP ausgeben: createImageBitmap plus OffscreenCanvas.convertToBlob, im Worker. Schnell, universell, angenehm langweilig.
• AVIF oder JPEG XL: ein WASM-Encoder oder ein Server. Kein Canvas.
• Palette eines PNG reduzieren: ein WASM-Build von pngquant. Canvas kann es nicht.
• EXIF oder ICC erhalten: vor dem Kodieren mit einer Bibliothek wie piexifjs auslesen und danach wieder einsetzen, denn Canvas behält nichts davon.

Wer den Qualitätskompromiss sehen will, ohne etwas davon zu schreiben: Unser Bildkompressor zeigt die Grösse vor und nach dem Verschieben des Reglers, und der Bildgrössen-Änderer übernimmt die Dimensionen. Beide laufen vollständig im Tab.

Der Browser ist eine leistungsfähige Bild-Laufzeit mit zwei scharfen Kanten: Er schweigt über Formate, die er nicht kodieren kann, und er hält dekodierte Pixel unkomprimiert. Wer um diese beiden herum entwirft, hat den Rest geschenkt.