Dateien vor dem Senden komprimieren: Größe reduzieren

Komprimieren Sie Texte, Quellcode, Logs, CSVs und unkomprimierte Bildformate wie .bmp oder .tiff vor dem Senden — erwarten Sie eine 3- bis 10-fache Größenreduzierung. Komprimieren Sie keine .jpg-, .png-, .mp4-, .mp3-, .docx-, .xlsx-, .pdf- oder .zip-Dateien — sie sind bereits intern komprimiert, und ein zweiter Durchgang spart höchstens 2–3 % unter CPU-Einsatz. Zum Bündeln vieler kleiner Dateien in einen Upload verwenden Sie .zip im Store-Modus (keine Kompression). Für maximale Ratio bei komprimierbaren Daten schlägt 7z mit LZMA2 typischerweise .zip um 30–40 %. RAR ist .zip in etwa gleichwertig, erfordert aber, dass der Empfänger WinRAR oder 7-Zip installiert hat — .zip ist universell unterstützt.

Wann Kompression wirklich hilft

Textdateien komprimieren dramatisch. Eine 10-MB-Server-.log-Datei schrumpft oft auf 800 KB mit .zip (12-fach) und auf 550 KB mit 7z (18-fach). Kompression funktioniert, weil Logs hochgradig repetitive Muster enthalten — Zeitstempel, IP-Adressen, HTTP-Status-Codes — die Kompressionsalgorithmen effizient ausnutzen.

Ähnlich komprimierbare Kategorien:

• Quellcode: .js, .py, .java, .cs, .go — typischerweise 3- bis 5-fache Kompression
• CSV-Daten: 4- bis 10-fach je nach Inhaltsredundanz
• JSON/XML: 5- bis 8-fach wegen wiederholter Feldnamen
• Unkomprimierte Bilder: .bmp (5- bis 10-fach), .tiff unkomprimiert (4- bis 8-fach)
• Datenbanken: .sql-Dumps, SQLite-Dateien mit freien Seiten (2- bis 4-fach)
• PSD-Flat-Layer: 2- bis 3-fach, wenn nicht bereits intern RLE-komprimiert

Ein Git-Repository-Tarball eines mittelgroßen Projekts komprimiert oft 4- bis 5-fach — deshalb packt git archive den Baum standardmäßig in .tar.gz.

Wann Kompression sinnlos ist

Bereits komprimierte Formate werden nicht kleiner. Die zugrundeliegenden Daten wurden bereits durch DEFLATE, H.264, JPEG-DCT-Quantisierung oder ein ähnliches Schema verarbeitet — die Entropie liegt bereits nahe am theoretischen Minimum.

Dateien, die nicht profitieren:

• .jpg, .jpeg, .heic: verlustbehaftete Kompression bereits angewendet
• .png: DEFLATE-Kompression eingebaut
• .mp4, .mov, .mkv: H.264- oder H.265-Kompression bereits angewendet
• .mp3, .aac, .flac, .ogg: Audio bereits komprimiert
• .pdf: interne Objekt-Streams typischerweise DEFLATE-komprimiert
• .docx, .xlsx, .pptx: tatsächlich ZIP-Archive aus XML — nochmaliges Zippen ist redundant
• .zip, .7z, .rar, .gz, .bz2, .xz: komprimierte Archive; ein weiterer Durchgang ist sinnlos
• .apk, .jar, .war: ZIP-basierte Java/Android-Archive

Diese zu komprimieren verschwendet CPU und lässt die Datei manchmal durch Archive-Metadaten-Overhead sogar leicht wachsen.

ZIP vs. 7z vs. RAR

| Format | Typische Ratio | Geschwindigkeit | Empfänger-Kompatibilität | Verschlüsselung | |---|---|---|---|---| | .zip (DEFLATE) | Ausgangspunkt | Schnell | Universal (integriert in Windows, macOS, Linux) | ZIP 2.0 (schwach), AES-256 (meiste modernen Tools) | | .zip (DEFLATE64) | 5–10 % besser | Schnell | Windows integriert, 7-Zip, einige macOS-Tools | Wie .zip | | 7z (LZMA2) | 30–40 % besser als .zip | Langsamer | Erfordert 7-Zip, Keka oder The Unarchiver | AES-256 integriert | | .rar (RAR5) | ~25–35 % besser als .zip | Mittel | Erfordert WinRAR oder 7-Zip; nicht kostenlos erstellen | AES-256 integriert | | .tar.gz | Ähnlich wie .zip | Schnell | Integriert in macOS, Linux; 7-Zip auf Windows nötig | Keine nativ | | .tar.zst (Zstandard) | Zwischen .zip und 7z | Sehr schnell | Erfordert zstd (noch nicht universell) | Keine nativ |

Für Portabilität bleibt .zip die sicherste Wahl. Für Ratio gewinnt 7z. Für Geschwindigkeit und moderne Effizienz ist Zstandard (.zst) ausgezeichnet, aber Empfänger brauchen passende Werkzeuge.

„Store"-Modus zum Bündeln

Wenn Sie 200 .jpg-Fotos in einem Transfer senden, möchten Sie sie trotzdem in einem einzigen Archiv, damit der Empfänger einmal „Herunterladen" klickt. Verwenden Sie .zip mit Kompressionsstufe 0 (Store-Modus). Das Archiv ist die Summe der Dateigrößen plus ein paar Kilobytes Verzeichnis-Overhead — und die CPU-Kosten für die Erstellung sind nahezu null.

In 7-Zip: Zu Archiv hinzufügen → Kompressionsstufe → Speichern. In macOS Finder: Rechtsklick → Komprimieren (nutzt DEFLATE standardmäßig, was .jpg nicht hilft, aber auch nicht schadet). In der Befehlszeile: zip -0 bundle.zip *.jpg.

Verschlüsselung beim Komprimieren

Passwortgeschützte ZIP-Dateien mit AES-256 (nicht die veraltete ZIP-2.0-Verschlüsselung) sind eine vertretbare Option für sensible Nutzlasten, wenn Sie sich nicht auf die Sicherheit des Transferkanals verlassen können. WinRAR, 7-Zip und macOS' Archiv-Dienstprogramm unterstützen alle AES-256-ZIP-Verschlüsselung.

Der Haken: Passwortaustausch. Senden Sie das Passwort nicht in derselben Nachricht wie das ZIP. Schicken Sie die Datei, dann teilen Sie das Passwort über Signal, iMessage oder einen separaten Kanal. Noch besser: Nutzen Sie einen Transferdienst mit integriertem Passwortschutz, der die Komplexität für Sie handhabt.

ZIP-2.0-Verschlüsselung (manchmal noch Standard in älteren Tools) ist kryptografisch gebrochen — mit Known-Plaintext-Angriffen in Sekunden wiederherstellbar. Prüfen Sie immer, ob Sie AES-256 nutzen, wenn Sie sich für Sicherheit auf Archiv-Verschlüsselung verlassen.

Abwägung: CPU-Zeit vs. eingesparte Bytes

Kompression ist ein Zeit-Größen-Kompromiss. Maximale 7z-Kompression eines 5-GB-Textarchivs kann auf einem Laptop 30 Minuten dauern und 2 GB gegenüber .zip einsparen. Wenn der Transfer größenbegrenzt ist (Dienst mit 2-GB-Obergrenze), lohnt sich das. Wenn der Transfer zeitkritisch ist und Bandbreite günstig ist, lädt dieselbe 5-GB-Datei über Glasfaser in 90 Sekunden hoch — die halbe Stunde Kompression hätte mehr Zeit gekostet als sie gespart hätte.

Faustregel: Komprimieren, wenn das Netzwerk im Vergleich zur CPU langsam ist; nicht komprimieren, wenn das Netzwerk im Vergleich zur CPU schnell ist.

Große Archive aufteilen

Wenn eine Datei die Obergrenze eines Transferdienstes übersteigt, ist das Aufteilen in Volumes eine Option. 7-Zip und WinRAR unterstützen beide mehrteilige Archive (.7z.001, .7z.002 oder .part1.rar, .part2.rar). Jeder Teil kann als separater Transfer hochgeladen werden; der Empfänger lädt alle Teile herunter und extrahiert sie.

Das funktioniert, ist aber fehleranfällig — fehlt ein einziger Teil, ist das gesamte Archiv unbrauchbar. Besser, wenn möglich: Nutzen Sie einen Dienst mit größerer Obergrenze. SwissTransfers 50-GB-Limit macht das Aufteilen in den meisten realen Fällen überflüssig.

Verlustbehaftete Kompression als Alternative

Manchmal ist das Ziel nicht Archiv-Kompression, sondern Dateiformat-Kompression. Eine 200-MB-.wav-Audiodatei wird zu einer 15-MB-320-kbps-.mp3 — verlustbehaftet, aber für gelegentliches Hören kaum wahrnehmbar. Ein 60-MB-unkomprimiertes-.tiff-Foto wird zu einer 5-MB-hochqualitativen-.jpg. Ein 4K-.mov-Video, neu kodiert in H.265 mit vernünftiger Bitrate, kann 3- bis 5-fach schrumpfen.

Gehen Sie damit bedacht um. Für Master-Dateien zerstört verlustbehaftete Konvertierung Information. Für Vorschauen oder Endlieferungen ist es das richtige Werkzeug. Tools: FFmpeg für Video/Audio, Handbrake für Video, ImageMagick für Bilder sowie die Exportdialoge in Photoshop, Final Cut Pro oder Premiere.

Was der Transferdienst ohnehin tut

Die meisten Transferdienste komprimieren in gewissem Maß während der Übertragung — TLS-Kompression ist aus Sicherheitsgründen deaktiviert, aber HTTP-gzip oder Brotli auf der API-Ebene greift gelegentlich für Metadaten. Die eigentliche Datei-Nutzlast wird serverseitig nicht komprimiert, weil der meiste Traffic bereits komprimierte Formate sind.

HexaTransfer und ähnliche Zero-Knowledge-Dienste können Nutzlasten serverseitig überhaupt nicht komprimieren, weil sie Chiffretext empfangen. Kompression muss auf dem Client vor der Verschlüsselung erfolgen — nach der Verschlüsselung ist der Chiffretext zufällig aussehend und inkompressibel. Das bedeutet, clientseitige Kompression ist der einzige Weg, die Größe bei einem E2EE-Dienst zu reduzieren.

Entscheidung nach Inhalt, nicht nach Gewohnheit

Der Hauptfehler ist reflexartiges „immer vor dem Senden zippen". Für einen Kunden, der 20 .pdf-Dokumente erhält, ist ein ZIP-Paket praktisch. Für einen Kunden, der ein 800-MB-.mp4 erhält, verschwendet das ZIP Zeit auf beiden Seiten. Passen Sie die Wahl dem Inhalt an.

Im Zweifel: roh senden. Der Empfänger kann nach dem Empfang immer zippen. Wenn mehrere Dateien gebündelt werden sollen, nutzen Sie Store-Modus-.zip. Wenn die Inhalte textlastig sind, nutzen Sie 7z für echte Einsparungen.

Fazit

Komprimieren Sie, wenn die Daten komprimierbar sind — Texte, Logs, Quellcode, Datenbanken. Nicht komprimieren, wenn die Daten bereits komprimiert sind — Fotos, Videos, Audio, PDFs, Office-Dokumente. Zum Bündeln: ZIP im Store-Modus. Für maximale Ratio bei Texten: 7z mit LZMA2. Verschlüsseln Sie mit AES-256-Archivpasswörtern nur als Ergänzung zu einem sicheren Transferkanal, nicht als Ersatz dafür.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.