Wie clientseitige Dateikomprimierung funktioniert (und warum sie privater ist)

Wenn du auf den meisten Websites ein Foto komprimierst oder ein PDF verkleinerst, macht deine Datei eine Rundreise: Sie wird auf einen Server hochgeladen, irgendwo in einem Rechenzentrum verarbeitet, und eine kleinere Version wird an dich zurückgeschickt. Es funktioniert, aber es bedeutet, dass eine Kopie deiner privaten Datei kurzzeitig auf einem Computer liegt, den du nicht kontrollierst. FileShrinking verfolgt einen anderen Ansatz — jedes Byte der Komprimierung geschieht direkt in deinem eigenen Browser-Tab, und deine Dateien verlassen niemals dein Gerät. Dieser Artikel erklärt genau, wie das möglich ist, welche Browser-Technologien es ermöglichen und welche ehrlichen Kompromisse damit verbunden sind.

Zwei Wege, eine Datei im Web zu komprimieren

Das traditionelle Modell ist serverseitig. Dein Browser sendet die Originaldatei über das Netzwerk; ein Backend, das ein Werkzeug wie ImageMagick oder FFmpeg ausführt, erledigt die Schwerarbeit; das Ergebnis wird zurückgestreamt. Der Rechner des Nutzers gerät kaum ins Schwitzen, und der Server kann enorm leistungsfähig sein. Der Preis sind Datenschutz und Vertrauen: Deine Daten werden übertragen, sie liegen (wenn auch nur vorübergehend) auf der Festplatte einer anderen Person, und du musst ihr Wort darauf nehmen, was danach mit ihnen geschieht.

Das neuere Modell ist clientseitig. Dieselben Komprimierungsalgorithmen laufen direkt auf deinem Gerät, im Browser, ganz ohne Upload-Schritt. Jahrelang war das unpraktikabel — JavaScript allein war zu langsam, um einen ernsthaften Bild- oder Video-Codec mit brauchbarer Geschwindigkeit auszuführen. Das änderte sich, als Browser die Fähigkeit erhielten, kompilierten, nahezu nativen Code im Web auszuführen. Heute kann ein modernes Notebook oder Smartphone die Arbeit erledigen, die früher einen Server erforderte, und FileShrinking ist vollständig auf diesem Modell aufgebaut.

WebAssembly: echte Codecs, die im Browser laufen

Die Technologie, die clientseitige Komprimierung praktikabel macht, ist WebAssembly (oft als Wasm abgekürzt). Es ist ein kompaktes, hardwarenahes binäres Befehlsformat, das Browser mit Geschwindigkeiten nahe an nativem Code ausführen können. Entscheidend ist, dass es Entwicklern ermöglicht, Codecs, die in C, C++ oder Rust geschrieben — und über Jahrzehnte verfeinert — wurden, für die Ausführung im Web zu kompilieren, ohne sie in JavaScript neu zu schreiben.

So landen dieselben kampferprobten Komprimierungs-Engines, die du in professioneller Desktop-Software finden würdest, am Ende in einem Browser-Tab:

MozJPEG für hochwertige JPEG-Kodierung, die mehr aus jedem Kilobyte herausholt.
OxiPNG für verlustfreie PNG-Optimierung.
libwebp und AVIF-Encoder für die modernen Formate WebP und AVIF.
FFmpeg, zu WebAssembly kompiliert, zum Transkodieren und Verkleinern von Videos.

Für eine tiefergehende technische Referenz ist die WebAssembly-Dokumentation von MDN die maßgebliche Quelle dafür, wie das Format funktioniert und warum es schnell ist.

Web Workers: die Seite reaktionsfähig halten

Komprimierung ist rechenintensiv. Würdest du eine Video-Transkodierung im Haupt-Thread des Browsers ausführen, würde die gesamte Seite einfrieren — Schaltflächen würden nicht mehr reagieren, das Scrollen würde ruckeln und Fortschrittsbalken würden hängen bleiben. Um das zu vermeiden, führt FileShrinking die Arbeit in einem separaten Thread mit Web Workers aus.

Ein Web Worker ist ein JavaScript-Kontext im Hintergrund, der parallel zur Benutzeroberfläche läuft. Der Haupt-Thread übergibt die Datei (und den Wasm-Codec) an den Worker, der Worker arbeitet sich durch die Komprimierung und sendet das fertige Ergebnis zurück, wenn er fertig ist. Währenddessen bleibt die Oberfläche flüssig und kann den Fortschritt in Echtzeit anzeigen. Der MDN-Leitfaden zur Verwendung von Web Workers behandelt das Modell der Nachrichtenübermittlung im Detail. Große Binärdaten lassen sich mithilfe übertragbarer Objekte effizient zwischen Threads verschieben, sodass die Datei nicht Byte für Byte kopiert werden muss, nur um die Thread-Grenze zu überqueren.

Dateien ohne Netzwerk lesen und dekodieren

Bevor überhaupt etwas komprimiert werden kann, muss der Browser deine Datei in den Speicher einlesen und dekodieren. Das stützt sich auf eine kleine Familie standardisierter Web-APIs, von denen keine einen Server beteiligt:

Die File- und Blob-APIs repräsentieren die Datei, die du auswählst oder hineinziehst. Sie stellen die Rohdaten als ArrayBuffer bereit, auf dem Codecs direkt arbeiten können — alles im Speicher.
createImageBitmap dekodiert ein Bild effizient in eine verarbeitungsbereite Form und kann das außerhalb des Haupt-Threads tun.
OffscreenCanvas ermöglicht es dem Browser, Bilddaten innerhalb eines Workers zu zeichnen, zu skalieren und neu zu kodieren, ohne jemals die sichtbare Seite zu berühren.

Zusammengesetzt sieht die Verarbeitungskette so aus: Du legst eine Datei ab, der Browser liest ihre Bytes lokal, ein Worker dekodiert sie, der Wasm-Codec kodiert sie in der von dir gewählten Qualität neu, und ein neuer Blob wird dir zum Herunterladen zurückgegeben. Zu keinem Zeitpunkt reist die Datei irgendwohin. Falls dich die Qualitätsentscheidungen in diesem Neukodierungsschritt interessieren, erklärt unser Leitfaden zur verlustbehafteten gegenüber verlustfreien Komprimierung , was tatsächlich verworfen wird und warum.

Warum das wirklich privater ist

Der Datenschutzvorteil des clientseitigen Modells ist kein Marketing-Slogan — er ist eine direkte Folge der Architektur. Da deine Datei nur in den lokalen Speicher eingelesen und auf deinem Gerät neu kodiert wird:

Es wird nichts übertragen. Es gibt keinen Upload, also keine Kopie deiner Datei während der Übertragung, die abgefangen werden könnte, und keine ruhende Kopie auf einem Server, die gehackt, verkauft oder gerichtlich angefordert werden könnte.
Es funktioniert offline. Sobald die Seite und ihre Wasm-Codecs geladen sind, kannst du dich vollständig vom Internet trennen, und die Werkzeuge funktionieren weiter. Das ist der einfachste Beweis dafür, dass kein Upload stattfindet — du kannst es selbst im Netzwerk-Tab deines Browsers beobachten.
Es gibt nichts zu speichern. Wenn du den Tab schließt, sind die Dateidaten aus dem Speicher verschwunden. Es gibt keine Server-Protokolle, die deine Dokumente mit deiner Identität verknüpfen.

Und da FileShrinking vollständig quelloffen unter der MIT-Lizenz ist, musst du diese Behauptungen nicht einfach glauben. Jeder kann den Code lesen, bestätigen, dass es keinen Upload-Pfad gibt, und genau überprüfen, wie sich die Komprimierungskette verhält. Überprüfbarer Datenschutz ist die stärkste Form.

Die ehrlichen Kompromisse

Clientseitige Komprimierung ist keine Zauberei, und es ist nur fair, offen darüber zu sprechen, wo das Servermodell noch Vorteile hat:

Geschwindigkeit bei sehr großen Aufgaben. Ein Rechenzentrum kann einem langen Video weit mehr Kerne widmen, als dein Notebook hat. Bei den meisten Bildern und kurzen Clips ist der Unterschied nicht spürbar, aber ein abendfüllendes Video ist im Browser langsamer als auf einer Serverfarm.
Speichergrenzen. Alles geschieht im Arbeitsspeicher deines Geräts. Extrem große Dateien — etwa ein mehrere Gigabyte großes Video auf einem Smartphone mit wenig Speicher — können an Speicherobergrenzen des Browsers stoßen, die ein Server nicht hätte.
Kosten beim ersten Laden. Die Wasm-Codecs müssen beim ersten Mal, wenn du ein Werkzeug verwendest, heruntergeladen werden. Danach werden sie zwischengespeichert, sodass spätere Besuche sofort erfolgen, aber der allererste Durchlauf bezahlt einen einmaligen Download.

Für die überwältigende Mehrheit der alltäglichen Aufgaben — Fotos fürs Web optimieren, ein PDF auf E-Mail-Größe stutzen, eine Bildschirmaufnahme verkleinern — sind diese Kompromisse die Sache leicht wert, und du bekommst Datenschutz obendrein.

Überzeuge dich selbst

Der beste Weg, clientseitige Komprimierung zu verstehen, ist, sie zu nutzen. Probiere den Bildkompressor, den Videokompressor oder den PDF-Kompressor — öffne dann die Entwicklerwerkzeuge deines Browsers, beobachte den Netzwerk-Tab und bestätige, dass nichts hochgeladen wird, während deine Datei schrumpft. Alles läuft lokal, der Code ist für jeden einsehbar, und deine Dateien bleiben genau dort, wo sie hingehören: bei dir.