Shipping Archives Safely: Avoiding Corruption When Sending ZIPs
ZIP files are binary packages, and some transfer methods quietly change bytes in ways that break them. This guide explains why archives get corrupted in transit and how to choose reliable channels and simple safeguards so your compressed files arrive intact.
Why archives break in transit
ZIP, 7z, RAR, and other archives are binary files—every byte matters. Some transfer paths and tools were designed for text, not binary, and they may perform transformations that are harmless for documents but fatal for archives. Classic examples include FTP in ASCII mode (which alters line endings), email systems that wrap lines or re-encode attachments through older gateways, and messaging apps that compress images or transcode media by default. Even security appliances and proxies can unzip, rescan, and repackage files on the fly. The result is a file that looks normal on arrival but fails to open because a few bytes changed along the way.
Archive‑friendly delivery channels
Prefer channels that preserve bytes exactly: HTTPS downloads (from cloud storage or your own server), SFTP/FTPS, and dedicated file transfer services are generally safe. If you must use FTP, switch explicitly to binary mode before transferring. When sending via email, attach the ZIP as a file (not pasted inline) and ensure your client sends it as a proper attachment rather than inlined content. In chat apps, use the "send as file" option—avoid sending archives as images or media where the app might recompress them. When sharing via cloud drives, share the direct file link instead of zipping inside a document or embedding the archive in a page where viewers might receive a preview rather than the original.
Pre‑flight checks that protect your payload
Before sending, give your archive the best chance of surviving the trip. Keep the filename simple (letters, numbers, hyphens) to minimize the odds that a gateway will rename or sanitize it into something unexpected. If you need to split an archive for distribution, use the format’s native multi‑part feature (e.g., .z01/.zip pairs or 7z .001/.002 sequences) and send all parts together—missing segments are a common failure point. Include a small checksum file (e.g., SHA‑256) alongside the archive so the recipient can verify integrity after download. If the recipient might open the archive directly in a browser, store rather than compress already‑compressed media (like JPEG/MP4) so the archive isn’t needlessly complex to stream or inspect online.
Verify on arrival and handle hiccups
On the receiving end, verify before you extract. First, compare the file size you received to the sender’s size; large mismatches suggest a truncated transfer. Next, check the checksum if provided—matching values confirm the archive’s bytes are identical. If a multi‑part archive is involved, ensure every segment is present and in the same folder; missing or out‑of‑order parts will prevent reassembly. Only after these checks should you open or extract. If verification fails, re-download using a binary‑safe channel and avoid in-browser previews or proxying links through services that might transform the file.