The file arrived corrupted: how to find out what actually broke

"It says the file is corrupt" covers at least five unrelated failures, and they have different fixes. One check separates most of them, and it takes ten seconds.

Start with the size

Ask the sender for the exact byte count and compare it with what arrived. This single number identifies the cause more often than anything else you can do.

• Received file is much smaller — a few kilobytes. You almost certainly downloaded an error page. A server returning "403 Forbidden" or "Link expired" as HTML, saved under the filename you expected, produces a 2 KB "zip" that will never open. Open it in a text editor; you will read the error.
• Received file is somewhat smaller. Truncated download — the connection dropped and the browser saved what it had. Very common on flaky mobile connections and with single-request downloads that cannot resume.
• Sizes match exactly. The bytes are almost certainly fine, and the problem is on the opening side: a missing codec, the wrong application, an encoding mismatch, or a format the recipient's software does not support. This changes the whole investigation.

When the sizes match: checksums

If you need certainty rather than probability, compare a hash. Both sides run one command and read out a string; if the strings match, the files are byte-identical and the problem is definitively not the transfer.

• Windows: certutil -hashfile "file.zip" SHA256
• macOS / Linux: shasum -a 256 file.zip
• Comparing by eye: the first six and last six characters are plenty. If those match, the whole thing matches.

This is worth doing before anyone re-sends a multi-gigabyte file on a hunch. Half the time it proves the transfer was fine and saves an hour.

The other four causes

Antivirus or a mail gateway modified it. Security software routinely strips macros from Office files, removes executables from archives, and rewrites PDFs. The file opens but is missing something, or the archive reports one entry damaged. Usually silent. If a zip is fine on the sender's machine and broken on arrival at a corporate address, suspect this before the network.

A multi-part archive is missing a part. .z01, .part2.rar and friends are useless individually, and email filters love to quarantine exactly one of them. All parts must be in the same folder before you extract the first.

Text encoding. Turkish, and any non-ASCII text, arriving as ç, ı or ÅŸ means a UTF-8 file is being read as Windows-1252 or Latin-1. The bytes are intact; the reader guessed wrong. In Excel, do not double-click the CSV — use Data → From Text/CSV and set the origin to UTF-8. Saving as "CSV UTF-8" from Excel adds a byte-order mark that makes other tools guess right.

Line endings. Windows uses CRLF, Unix uses LF. Text files moved between them can open as one enormous line or show stray characters. Harmless for prose, occasionally fatal for scripts and config files.

Preventing the repeat

1. Prefer a transfer that verifies what it stored. A chunked upload that tracks which chunks arrived cannot silently deliver a truncated file — see how resume actually works.
2. Send the byte count with the file. One line in the message turns a vague "it is broken" into a ten-second diagnosis.
3. Never split archives to beat an email limit. Multi-part archives fail as a unit and are quarantined individually — use a different channel instead.
4. If the recipient is on a corporate address, expect inspection. Send archives without macros and executables, or send through a channel their IT sanctions.

More guides