How to Know a Received File Is Complete and Uncorrupted
“Transfer complete” and “the file is intact” are different claims. A tool can finish sending bytes and still deliver a corrupted file, because of a bug, an aborted retry, a disk error, or the source file changing mid-read. The only trustworthy completion signal is a checksum computed independently on both ends.
How ShareDrop.org verifies every file
- The sender hashes each 64 KiB chunk into a running SHA-256 as it reads and sends it.
- The receiver hashes the same chunks as it writes them to their destination.
- After the last chunk, the sender transmits its final digest.
- The receiver compares digests. Equal → the file is marked done. Different → the file is marked failed, the partial data is discarded (not left behind as a plausible-looking file), and the sender is told.
The ShareDrop.org engine test suite includes a deliberate corruption test (one flipped byte in a 100 KB transfer) and asserts that both sides report failure and the receiver discards the data. A verification system you have never seen fail is a verification system you should not trust.
Why hash during, not after
Hashing a received file “at the end” would require reading it back — slow for multi-gigabyte files and impossible in browsers that only had a streaming path to disk. Incremental hashing costs almost nothing per chunk, keeps memory flat, and also detects a subtle failure: a source file that changes while being sent produces a digest matching neither the old nor the new version, and the mismatch surfaces immediately.
Verifying a file yourself, on any platform
If you ever want to double-check a file against a hash someone gave you:
# macOS / Linux
shasum -a 256 yourfile.zip
# Windows PowerShell
Get-FileHash yourfile.zip -Algorithm SHA256Identical output = identical file, byte for byte. SHA-256 collisions are not a practical concern; for transfer integrity it is effectively a unique fingerprint of the content.
The four ways a file goes wrong
| Failure | How it happens | What you would see without a check |
|---|---|---|
| Truncation | The connection drops after most of the file has arrived; the tool saves what it has | A video that stops at 87%, a ZIP that “is corrupt”, a PDF that opens with missing pages |
| Bit flips | Failing storage, a bad cable, faulty memory on either device | A photo with a coloured band, a document with one strange character, an installer that fails to verify |
| Partial write | The receiving disk fills up mid-file; the operating system reports success for what fit | A file of the right name and the wrong size; often noticed weeks later |
| Misassembly | Chunks written out of order or into the wrong file after a reconnect | A file of the right size that is subtly wrong throughout |
A hash comparison catches all four, because all four change the bytes. That is the whole argument for hashing at the end of every file rather than trusting the transport: the transport guarantees each packet arrived intact, and says nothing about whether the file on disk is what the sender had.
Checksums are not signatures
A matching hash proves the bytes are identical to the sender's. It does not prove who the sender is: an impostor who intercepted the introduction could send you their file with their correct hash and it would verify perfectly. Integrity and authenticity are separate questions with separate answers: the hash for the first, the safety code for the second. A transfer with both is one where the file is intact and came from the device you think it did. A digital signature would answer both at once, but needs a long-term key for the sender, which an account-free tool does not have.
Why SHA-256, and not CRC32, MD5 or SHA-1
| Algorithm | Catches accidental corruption | Resists deliberate forgery | Where it is still fine |
|---|---|---|---|
| CRC32 | Yes, for small random errors | No: trivial to forge | Inside ZIP files and network frames, against line noise |
| MD5 | Yes | No: collisions are cheap since 2004 | Detecting accidental changes to files nobody is attacking |
| SHA-1 | Yes | No: practical collisions since 2017 | Legacy systems; avoid for anything new |
| SHA-256 | Yes | Yes, with no known practical attack | Everything, including this |
For a transfer tool the difference matters in one scenario: an attacker who can alter the file in transit and also alter the hash you compare against. With SHA-256 they cannot craft a different file with the same hash, so a hash obtained through a channel they do not control is a real check. With MD5 or CRC they could.
How fast hashing is
Modern CPUs have dedicated SHA-256 instructions, and even without them the algorithm runs at hundreds of megabytes per second in a browser through the Web Crypto API and well over a gigabyte per second natively. A file transfer over any real network is far slower than that, which is why hashing every chunk as it passes costs nothing you can measure: in ShareDrop.org's same-machine benchmark the full pipeline sustains 200+ Mbps with SHA-256 running on both ends, and the hash is never the limiting step. The only way verification becomes visible is if a tool waits until the end and reads the whole file again from disk: a design choice, not a property of hashing (what that looks like).
Comparing hashes by hand without making mistakes
- Let the tool compare when it can:
sha256sum -con Linux and macOS, orGet-FileHashpiped to a comparison in PowerShell, is faster and less error-prone than reading 64 characters aloud. - If you must compare visually, check the first eight and the last eight characters. The odds of a corrupted or substituted file matching sixteen hexadecimal characters by chance are negligible; reading the whole string adds nothing but fatigue.
- Get the reference hash from somewhere the file did not come through. A hash pasted in the same email as a tampered attachment proves only that the attacker can compute SHA-256.
- Case does not matter;
a3f…andA3F…are the same hash. A trailing space or line break in a pasted hash is the most common reason a manual comparison “fails.”
Frequently asked
Does verification make the transfer slower?
Not measurably, if it is done incrementally. If a tool pauses at the end to hash, that pause is the cost of not having hashed along the way.
The hashes differ. Now what?
Retry the transfer. A second mismatch on the same file points at the storage on one side (run a disk check), or at a file that is still being written by another program on the sender. A mismatch that appears only over one network and not another is worth reporting; it should not happen with an encrypted transport and would indicate a bug.
My ZIP has its own checksum: is that enough?
ZIP stores a CRC32 per file, which catches accidental corruption of the archive's contents when you extract. It does not verify that the archive you received is the one that was sent, and it is easily forged. Treat it as a second net, not the first.
For recurring transfers: automate it
If the same folders move between the same machines regularly, stop comparing by hand. On the source, generate a manifest once, find . -type f -exec sha256sum + > manifest.sha256, send it along with the files, and on the destination run sha256sum -c manifest.sha256, which prints one line per file and a clear FAILED for any that differ. rsync --checksum does the equivalent inline for machines you can reach over SSH, comparing content rather than timestamps. A tool that verifies each file as it lands, as ShareDrop.org does, makes this a second check rather than the first, but for archives that will be read years later, a manifest stored beside the files is the only check that still works when the transfer tool is long gone.
What integrity checking does not cover
- It proves the file matches what the sender had, not that the content is safe or what you expected. Scan files from strangers as you would any download.
- It complements, not replaces, transport encryption and identity verification (encryption, safety codes): three different failure modes, three different mechanisms.
How this is tested
- Corruption must be caught: the engine test suite deliberately flips bytes and drops chunks mid-stream, then asserts the transfer ends in a checksum failure, never in a “done” state with a silently broken file. These tests run on every change to the engine.
- Verification must be affordable: hashing is incremental over the same 64 KiB chunks the transfer already uses, so there is no second pass over the file. In ShareDrop.org's same-machine benchmark the pipeline sustains 200+ Mbps with SHA-256 running on both ends — integrity is not a speed tax you need to opt out of.
Standards referenced
- NIST FIPS 180-4: Secure Hash Standard: the SHA-256 specification.
- RFC 6234: US Secure Hash Algorithms: SHA-256 reference implementation and test vectors.
- W3C Web Cryptography API: the browser-native digest primitives used for hashing.
