Compress Files Before Sending: Reduce Size & Save Time

Compress text, source code, logs, CSVs, and uncompressed image formats like .bmp or .tiff before sending — expect 3-10x size reduction. Don't compress .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf, or .zip files — they're already compressed internally, and a second pass adds at most 2-3% savings while burning CPU. For bundling many small files into one upload use .zip in store mode (no compression). For maximum ratio on compressible data, 7z with LZMA2 typically beats .zip by 30-40%. RAR is broadly equivalent to 7z but requires the recipient to have WinRAR or 7-Zip installed — .zip is universally supported.

When compression actually helps

Text files compress dramatically. A 10 MB server .log file often shrinks to 800 KB with .zip (12x), and to 550 KB with 7z (18x). Compression works because logs contain highly repetitive patterns — timestamps, IP addresses, HTTP status codes — that compression algorithms exploit efficiently.

Similarly compressible categories:

• Source code: .js, .py, .java, .cs, .go — typically 3-5x compression
• CSV data: 4-10x depending on content redundancy
• JSON/XML: 5-8x because of repeated field names
• Uncompressed images: .bmp (5-10x), .tiff uncompressed (4-8x)
• Databases: .sql dumps, SQLite files with free pages (2-4x)
• PSD flat layers: 2-3x if not already RLE-compressed internally

A Git repository tarball of a moderate-sized project often compresses 4-5x, which is why git archive wraps the tree in .tar.gz by default.

When compression is pointless

Already-compressed formats don't get smaller. The underlying data has been through DEFLATE, H.264, JPEG DCT quantization, or a similar scheme already — the entropy is already near the theoretical minimum.

Files that don't benefit:

• .jpg, .jpeg, .heic: lossy compression already applied
• .png: DEFLATE compression built in
• .mp4, .mov, .mkv: H.264 or H.265 compression already applied
• .mp3, .aac, .flac, .ogg: audio already compressed
• .pdf: internal object streams typically DEFLATE-compressed
• .docx, .xlsx, .pptx: these are actually ZIP archives of XML — re-zipping is redundant
• .zip, .7z, .rar, .gz, .bz2, .xz: compressed archives; another pass is futile
• .apk, .jar, .war: ZIP-based Java/Android archives

Compressing these wastes CPU and sometimes slightly grows the file because of archive metadata overhead.

ZIP vs 7z vs RAR

| Format | Typical ratio | Speed | Recipient compatibility | Encryption | |---|---|---|---|---| | .zip (DEFLATE) | Baseline | Fast | Universal (built into Windows, macOS, Linux) | ZIP 2.0 (weak), AES-256 (most modern tools) | | .zip (DEFLATE64) | 5-10% better | Fast | Windows built-in, 7-Zip, some macOS tools | Same as .zip | | 7z (LZMA2) | 30-40% better than .zip | Slower | Requires 7-Zip, Keka, or The Unarchiver | AES-256 built in | | .rar (RAR5) | ~25-35% better than .zip | Medium | Requires WinRAR or 7-Zip; not free to create | AES-256 built in | | .tar.gz | Similar to .zip | Fast | Built into macOS, Linux; needs 7-Zip on Windows | None native | | .tar.zst (Zstandard) | Between .zip and 7z | Very fast | Requires zstd (not universal yet) | None native |

For portability, .zip remains the safest choice. For ratio, 7z wins. For speed and modern efficiency, Zstandard (.zst) is excellent but recipients need tooling that supports it.

"Store" mode for bundling

If you're sending 200 .jpg photos in one transfer, you still want them in a single archive so the recipient clicks "download" once. Use .zip with compression level 0 ("store" mode). The archive is the sum of the file sizes plus a few kilobytes of directory overhead — and the CPU cost of creating it is near zero.

In 7-Zip: Add to archive → Compression level → Store. In macOS Finder: Right-click → Compress (uses DEFLATE by default, which won't help on .jpg but doesn't hurt much). In the command line: zip -0 bundle.zip *.jpg.

Encryption when compressing

Password-protected ZIP files using AES-256 (not the legacy ZIP 2.0 encryption) are a reasonable transport for sensitive payloads when you can't rely on the transfer channel's security. WinRAR, 7-Zip, and macOS's Archive Utility all support AES-256 ZIP encryption.

The catch: password exchange. Don't email the password in the same message as the ZIP. Send the file, then share the password via Signal, iMessage, or a separate channel. Better: use a transfer service with built-in password protection, which handles the complexity for you.

Legacy ZIP 2.0 encryption (still sometimes the default in older tools) is cryptographically broken — recoverable in seconds with known-plaintext attacks. Always verify you're using AES-256 if relying on archive encryption for security.

Trade-off: CPU time vs bytes saved

Compression is a time/size trade-off. Maximum 7z compression on a 5 GB text archive might take 30 minutes on a laptop and save 2 GB over .zip. If the transfer is size-constrained (a service with a 2 GB ceiling), that's worth it. If the transfer is time-constrained and bandwidth is cheap, the same 5 GB uploads in 90 seconds over fiber — the half-hour of compression would have cost you more time than it saved.

Heuristic: compress when the network is slow relative to the CPU; don't bother when network is fast relative to CPU.

Splitting large archives

When a file exceeds a transfer service's ceiling, splitting into volumes is an option. 7-Zip and WinRAR both support multi-part archives (.7z.001, .7z.002, or .part1.rar, .part2.rar). Each part can be uploaded as a separate transfer; the recipient downloads all parts and extracts.

This works but is fragile — if any single part is missing, the whole archive is unusable. Better when possible: use a service with a larger ceiling. SwissTransfer's 50 GB limit removes the need for splitting in most realistic cases.

Lossy compression as an alternative

Sometimes the goal isn't archive compression but file-format compression. A 200 MB .wav audio file becomes a 15 MB 320 kbps .mp3 — lossy but nearly transparent for casual listening. A 60 MB uncompressed .tiff photo becomes a 5 MB high-quality .jpg. A 4K .mov video re-encoded to H.265 at reasonable bitrate might shrink 3-5x.

Use this judiciously. For master files, lossy conversion destroys information. For previews or deliverables, it's the right tool. Tools: FFmpeg for video/audio, Handbrake for video, ImageMagick for images, and the export dialogs in Photoshop, Final Cut Pro, or Premiere.

What the transfer service does anyway

Most transfer services compress in-flight to some degree — TLS compression is disabled for security reasons, but HTTP gzip or brotli on the API layer occasionally kicks in for metadata. The actual file payload isn't server-side compressed because most traffic is already-compressed formats.

HexaTransfer and similar zero-knowledge services can't compress payloads server-side at all because they receive ciphertext. Compression must happen on the client before encryption — after encryption, the ciphertext is random-looking and incompressible. This means client-side compression is the only way to reduce size when using an E2EE service.

Decide by content, not by habit

The main mistake is reflexive "always zip before sending." For a client receiving 20 .pdf documents, a ZIP bundle is convenient. For a client receiving one 800 MB .mp4, the ZIP wastes time on both sides. Match the choice to the content.

When in doubt: send raw. The recipient can always zip after receiving. If bundling multiple files, use store-mode .zip. If the contents are text-heavy, use 7z for real savings.

Verdict

Compress when the data is compressible — text, logs, source code, databases. Don't compress when the data is already compressed — photos, videos, audio, PDFs, office documents. For bundling, use ZIP in store mode. For maximum ratio on text, use 7z with LZMA2. Encrypt with AES-256 archive passwords only as a complement to a secure transfer channel, not as a replacement for one.

Try it at hexatransfer.com — free, no account, 10 GB max.