Du hast einen Haufen Fotos, die kleiner sein müssen, bevor du sie irgendwohin schicken kannst. Vielleicht das Produktfoto eines Kunden, das noch nicht öffentlich ist. Vielleicht der Geburtstag deines Kindes oder der Scan deines Reisepasses für ein Visum. Der Instinkt ist automatisch: eine Kompressor-Webseite öffnen, die Dateien reinziehen, die kleineren Versionen herunterladen. Ich habe das Jahre lang gemacht. Bis ich eines Tages innehielt und eine langweilige Frage stellte: nach dem Klick auf »Hochladen«, wo genau landen diese Bytes eigentlich?
Für einen serverbasierten Kompressor ist das der ganze Sinn des Dienstes. Dein Bild überquert das Netz zu einer Maschine, die dir nicht gehört, wird dort verarbeitet und das Ergebnis kommt zurück. Das sind drei Tatsachen, über die du nicht streiten kannst: die Datei verließ dein Gerät, landete auf Infrastruktur, die ein anderer kontrolliert, und eine Kopie von ihr existierte auf dieser Infrastruktur — wie kurz auch immer. Nichts davon ist an sich ein Skandal. Aber es ist eine Angriffsfläche, die du einem Dritten übergibst, und die meisten Menschen denken nie darüber nach, was auf der anderen Seite ist.
Was »lokal« wirklich bedeutet
Ein browser-nativer Kompressor macht das Gegenteil. Die Dateien werden von deinem eigenen Browser über die File API lokal gelesen, im Arbeitsspeicher deiner Maschine gehalten und an einen Web Worker übergeben, der die eigentliche Rechenarbeit der Kompression über WebAssembly ausführt — dieselben Motoren MozJPEG, WebP, OxiPNG und UPNG, die auch ein Server nutzen würde, nur dass sie auf deiner CPU laufen. Die Ausgabe ist ein Blob, den dein Browser direkt zu dir herunterlädt. Zu keinem Zeitpunkt öffnet das Bild eine Netzwerkverbindung irgendwohin. Es gibt keinen Upload-Schritt, weil am anderen Ende niemand die Pixel braucht, um seine Arbeit zu tun.
Das ist keine Marketingbehauptung, die du auf Glauben hinnehmen musst. Das Werkzeug auf dieser Seite ist genau so gebaut: das Upload-Modul ließt und prüft Dateien nur lokal; die Kompressions-Worker führen die Kodierung vollständig im Browser aus; das Ergebnis ist ein Blob, den du selbst speicherst. Kein Konto, kein API-Schlüssel, kein Hin-und-her. Wenn du im Browser den Netzwerk-Tab während der Kompression öffnest, siehst du null Anfragen, die Bilddaten tragen.
Risikokarte: womit die Upload-Route dich bloßstellt
Wenn du ein Bild zum Komprimieren hochlädst, tauschst du nicht einfach Bandbreite gegen Bequemlichkeit. Du übernimmst eine Reihe von Gefährdungen, die schlicht nicht existieren, wenn die Datei dein Notebook nie verlässt:
- Übertragung im Netz. Der Transfer selbst geht durch deinen Anbieter und alles, was zwischen dir und dem Server liegt. In einem geteilten oder öffentlichen WLAN ist das eine reale, langweilige Tatsache, kein Filmplot.
- Speicherung durch Dritte. Die Datei landet auf der Festplatte von jemand anderem. Sie geht in dessen Backup-Kette, dessen Aufbewahrungsrichtlinie und — unvermeidlich — dessen Breach-Fläche. Jeder Server, der deine Daten hält, ist ein Server, der kompromittiert werden kann.
- Bedingungen, die du nie gelesen hast. Upload-basierte Dienste reservieren in ihren AGB fast immer weitgehende Rechte, um den Inhalt, den du übergibst, zu speichern, zu verarbeiten oder anderweitig zu nutzen. Bevor du einen davon mit Kundenarbeit oder unveröffentlichten Designs betraust, lies den Teil der AGB, der über hochgeladene Inhalte spricht. Die meisten überspringen ihn. Genau da liegt der Punkt.
- Compliance-Lücken. Unter dem Prinzip der Datenminimierung (die Gesetzesfamilie DSGVO/RGPD/APPI/LGPD) ist das Senden personenbezogener Daten an einen Verarbeiter, den du nicht geprüft hast, eine echte Lücke — keine theoretische. Wenn das Foto Ausweise oder andere personenbezogene Daten enthält, ist »es wurde auf dem Server von jemandem komprimiert« keine Antwort, die du einem Auditor geben willst.
- Das Zeitalter des Modelltrainings. Einige Plattformen erklären offen, dass Uploads genutzt werden können, um ihre Modelle zu verbessern. Selbst wenn sie es nicht tun, sobald eine Kopie außerhalb deiner Kontrolle existiert, entscheidest du nicht mehr über ihr Schicksal.
Nichts davon bedeutet, dass jeder Cloud-Kompressor böswillig ist. Es bedeutet, dass die Upload-Route einen Preis hat, den das »kostenlos und schnell«-Pitch auslässt. Lokale Kompression streicht den Preis vollständig, weil es die Route nicht gibt.
Lokal gegen Cloud, gegenübergestellt
| Frage | Dieses Werkzeug (lokal) | Typischer Cloud-Kompressor |
|---|---|---|
| Wohin gehen die Bytes? | Nirgendwo — auf deinem Gerät verarbeitet | Zu einem Server eines Dritten |
| Konto nötig? | Nein | Meistens, bei Stapeln oder großen Dateien |
| Tempo bei 20 Fotos? | Sekunden, keine Warteschlange | Upload + Warten + Download |
| Maximale Dateigröße | 50 MB | Varriert; Free-Stufe deckelt tief |
| Was danach passiert | Nichts — keine Kopie bleibt | Eine Kopie existierte bei ihnen |
| Wasserzeichen / Free-Limit? | Keines | Oft ja, nach wenigen Bildern |
Echte Zahlen desselben Motors
Zur Klarheit: das ist nicht nur Gerede über Privatsphäre — der lokale Motor komprimiert wirklich. Ich habe ein Testfoto von 1600×1200 durch dieselbe Median-Cut-PNG8-Pipeline geschickt, die diese Seite nutzt:
| Methode | Dateigröße | Ersparnis |
|---|---|---|
| Originales RGB-PNG | 115,3 KB | — |
| PNG8 (256 Farben, 1-Bit-Alpha) | 10,7 KB | −90,8 % |
| JPEG Qualität 80 (repräsentativ) | ~32 KB | ~72 % |
Du gibst also bei Qualität oder Ratio nichts auf, wenn du lokal bleibst. Du bekommst die 90 %+-Schrumpfung und behälst die Datei auf deiner eigenen Hardware. Diese Kombination ist der ganze Grund, warum dieser Ansatz existiert.
Wann lokal klar die richtige Wahl ist
- Unveröffentlichte Arbeit oder Kunden-NDA. Produktfotos vor dem Launch, Designs unter Verschwiegenheitsvereinbarung, ein Logo, das der Kunde noch nicht freigegeben hat. Wenn es dich genieren würde, es auf dem Server von jemandem zu sehen, komprimiere es lokal.
- Persönliche und Familienfotos. Das, was du nie öffentlich posten würdest, aber trotzdem mailen oder hochladen musst. Halte es von Anfang bis Ende auf deinem Gerät.
- Ausweise. Reisepass-Scans, Visumfotos, KYC-Uploads. Genau das ist die Kategorie »personenbezogene Daten«, die Regulierer kümert, und sie sind oft zu groß für das Formular — genau der Moment, in dem Leute zu einem xbeliebigen Kompressor greifen. Mach es im Browser.
- Alles, was du nicht in ein öffentliches Formular einfügen würdest. Ein guter mentaler Test: wenn du es nicht an einen Tweet anhängen würdest, lade es nicht hoch, um es zu komprimieren.
- Wenn du einfach null Reibung willst. Keine Anmeldung, kein »Free-Stufe auf 5 Bilder begrenzt«, kein Wasserzeichen. Zwanzig Dateien, je bis 50 MB, in Sekunden.
Wann eine Cloud tatsächlich in Ordnung ist
Lokal ist nicht immer die Antwort. Wenn das Bild schon öffentlich ist — ein Meme, ein Screenshot einer öffentlichen Seite, Stock, den du mit Weitervertriebsrechten gekauft hast — ist die Upload-Bloßstellung bedeutungslos, und ein Cloud-Werkzeug mit einem Format, das dein lokales nicht hat (AVIF oder HEIC zum Beispiel, die diese Seite noch nicht behandelt), kann die pragmatische Wahl sein. Der Punkt ist, die Entscheidung bewusst zu treffen, nicht aus Reflex.
Der leise Vorteil, den niemand erwähnt
Weil nichts hochgeladen wird, gibt es keine Server-Warteschlange, kein Ratelimit, kein »bitte upgraden, um mehr als fünf Bilder zu komprimieren«. Du wirst nur von deiner eigenen Hardware begrenzt: bis zu 20 Dateien auf einmal, je bis 50 MB, parallel auf deiner Maschine komprimiert. Für jeden, der schon an der Free-Stufen-Mauer eines Cloud-Werkzeugs mitten in einer Aufgabe feststeckte, lohnt sich der Wechsel allein dafür.
Der Workflow, den ich nutze
- Werkzeug öffnen. Kein Login. Die Seite ist statisch, die Kompression läuft in einem Worker.
- Bis zu 20 Fotos reinziehen. JPEG, PNG und WebP gemischt in einem Stapel — das Werkzeug erkennt jedes Format.
- Qualität und Ausgabe wählen. Regler nach links für aggressive Schrumpfung, nach rechts für Archiv. Wähle, das Originalformat zu behalten oder zu konvertieren.
- Komprimieren und herunterladen. Ein Klick lädt alles als einzelne Dateien oder als Zip. Dateinamen bleiben erhalten.
- Tab schließen. Nichts bleibt auf irgendeinem Server, weil nie etwas dorthin gesendet wurde.
Verwandte Guides für konkrete Situationen
Dein Privatsphäre-Bedarf überlappt oft mit einer konkreten Kompressionsaufgabe. Diese Guides gehen tiefer auf angrenzende Themen ein:
- Produktfotos für einen Shop komprimieren (JPEG-Qualität, Plattformgrenzen, Zoom erhalten)? Der Produktfoto-Guide deckt es ab.
- Transparente Logos und Sticker komprimieren ohne weiche Ränder zu ruinieren? Der transparente-PNG-Guide erklärt die PNG8-Halo-Falle.
- Mit Screenshots umgehen, die in JPEG unscharf werden? Der Screenshot-Guide zeigt, warum PNG8 Text scharf hält.
- Auf ein bestimmtes Größenlimit kommen (unter 20 KB für ein Formular)? Der 20-KB-Guide geht den Workflow durch.
- Die Funktionsweise des Kompressors Schritt für Schritt sehen? Die Funktionsseite erklärt die Pipeline im Browser.
Zusammengefasst
Cloud-Kompressoren sind bequem, weil sie die Arbeit auf ihrer Netzseite erledigen — und diese Bequemlichkeit kostet dich eine Kopie deines Bildes auf Hardware, die du nicht kontrollierst, plus ein Konto, eine Warteschlange und meistens eine Free-Stufen-Mauer. Browser-native Kompression streicht diesen Preis: dieselben Motoren laufen auf deiner eigenen Maschine, es wird nichts hochgeladen, und du bekommst trotzdem die 90 %+-Schrumpfung. Greife zum lokalen Werkzeug, immer wenn das Foto privat, unveröffentlicht oder schlicht etwas ist, das du nicht in ein öffentliches Formular einfügen würdest. Behalte die Cloud-Option für Bilder, die schon öffentlich sind und ein Format brauchen, das dein lokales nicht hat.
Deine Fotos gehören dir. Sie sollten kleiner werden, ohne dein Gerät dafür zu verlassen.