File Corrupted After Transfer? How to Prevent Data Loss
Files corrupted after transfer? Learn why it happens and how to prevent it. Discover checksum verification and services that guarantee file integrity.
File corruption after transfer is rare on modern HTTPS-based services because TCP checksums, TLS 1.3 integrity, and AES-GCM authentication tags all catch bit errors in transit. When corruption does happen, it's usually on the endpoints: interrupted download that wrote a partial file, disk errors during write, or a bug in the client truncating streams. Verify with a SHA-256 hash on both sides. If the hashes match, the file is identical. If they don't, you re-transfer. Services that use AES-256-GCM provide built-in authentication, so a decryption success is itself proof of integrity.
Why transfers rarely corrupt in transit
Every HTTPS request carries a TLS integrity check. TLS 1.3 with AEAD ciphers like AES-256-GCM or ChaCha20-Poly1305 produces an authentication tag per record; if a bit flips on the wire, the tag verification fails and the record is rejected before it ever reaches the application. TCP adds its own 16-bit checksum per segment. The combined probability of a silent corruption passing both checks is astronomically low, around 1 in 2^128 for TLS alone.
Unencrypted protocols (FTP, plain HTTP) are less robust. TCP's checksum will miss some errors; bits can flip silently on intermediate hardware with bad RAM. This is a real reason to avoid plain FTP for large transfers, even beyond the credential-leak issue.
Where corruption actually happens
The common causes of post-transfer corruption, in rough order of frequency:
Interrupted download saved as partial file. Browser downloads that lose connection at 75 percent often save a 75-percent-complete file that looks "present" in Downloads but opens broken. Chrome and Firefox now typically flag these as .crdownload or .part, but older versions and some third-party managers don't.
Local disk write errors. A failing external drive, a full disk, or a bad sector causes the file to write partially. Windows won't always surface this cleanly; macOS sometimes does.
Antivirus quarantine modifying the file. Real-time AV sometimes strips executable sections or modifies archives mid-download to "sanitise" them, leaving the file technically present but logically corrupt.
Client bug truncating streams. Rare on well-maintained clients, but some legacy FTP clients, old versions of SyncToy, or custom upload scripts have known truncation bugs.
Verify with SHA-256 hashes
The only reliable way to prove a file transferred intact is to compute a cryptographic hash on both sides and compare. SHA-256 is universal, fast (500 MB/s on modern CPUs with AES-NI), and collision-resistant.
macOS/Linux: shasum -a 256 file.mov. Windows 10+: certutil -hashfile file.mov SHA256. Both produce a 64-character hex string. Send the hash alongside the link ("SHA256: a1b2c3...") so the recipient can verify after download.
If the hashes match, the file is bit-for-bit identical. If they differ, re-transfer.
AES-GCM gives you integrity for free
Services that encrypt with AES-256-GCM (authenticated encryption with associated data) include an authentication tag in every block. When the recipient decrypts, a failed tag verification means the ciphertext was tampered with or corrupted, and decryption fails hard with an error like "GCM authentication failed."
This means if a file decrypts successfully, it's guaranteed unmodified. No separate SHA-256 check needed on the recipient's side. HexaTransfer, Smash's Secure mode, SwissTransfer, Tresorit Send, and Proton Drive all use AES-GCM or XChaCha20-Poly1305 (similar authenticated mode) for exactly this reason.
Detect partial downloads
A telltale sign of a partial download: the file size on disk is smaller than what the transfer page advertised. Right-click the downloaded file, check size, compare to the sender's reported size. If they don't match, the download didn't finish.
Media files are good at surfacing this. A partial MP4 plays for a minute then cuts off. A partial ZIP returns "archive is corrupt" on extraction. A partial PDF shows the first few pages then errors. Text files often open fine but are truncated silently, which is the worst case because you don't notice.
Resumable downloads for flaky connections
If the recipient's connection drops during download, resume support matters. HTTP range requests (RFC 7233) let a client restart from an offset. curl handles it with -C -, wget with -c. Browser-based download managers vary; Firefox and Chrome resume within the same session if the server supports ranges.
Services that use plain POST or don't expose Range headers force a full restart on drop, which on a 10 GB file over 20 Mbps cellular is a very bad time.
Antivirus interference
Windows Defender, Avast, Bitdefender, and McAfee sometimes intercept downloads mid-stream to scan them. Usually that's transparent. Occasionally, for archive formats or executables, the AV decides to "clean" the file and strips contents or replaces the file with a quarantine stub.
If a file consistently downloads corrupt on the recipient's machine, have them disable real-time AV temporarily and retry. If the retry succeeds, the AV is the culprit. Add the transfer service's domain to the AV exclusion list.
Disk space and filesystem issues
A download can also corrupt if the destination disk fills up mid-write. macOS writes through to the APFS snapshot layer and usually surfaces errors cleanly. Windows NTFS tends to silently truncate. On external drives, check free space before starting a 10 GB download.
Filesystem bugs are rare but real. exFAT on older Windows versions has had truncation bugs with files over 4 GB historically. ext4, NTFS, and APFS are reliable on current OS versions.
Check with a media-specific validator
Video files: ffprobe -v error file.mp4 reports errors silently. If the output is empty, the container structure is intact. For in-depth, ffmpeg -v error -i file.mp4 -f null - walks every frame and reports decode errors.
PDFs: Acrobat's "Validate" command checks object structure. qpdf --check file.pdf does the same from the command line.
DICOM medical imaging: dcmdump file.dcm from DCMTK verifies required tags and structure, which matters for hospital PACS systems that reject invalid files.
Archives: unzip -t file.zip and 7z t file.7z test without extracting. Fast and catches most corruption.
Pick services with integrity built in
For critical transfers, pick a service that provides cryptographic integrity by design. End-to-end AES-GCM encryption, SHA-256 hash display on the download page, or explicit checksum validation in the client all give you proof rather than hope. HexaTransfer uses AES-256-GCM so successful decryption itself verifies the file hasn't been altered, and the 10 GB per-transfer ceiling covers most professional deliverables.
Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file