How to Know a Received File Is Complete and Uncorrupted

Transfer finished does not mean file intact. How end-to-end SHA-256 verification works and why ShareDrop.org refuses to mark a file done without it.

By ShareDrop.org Engineering · Published 2026-03-27 · Last verified 2026-08-08 · Tested against: Corrupted-chunk detection tests in the ShareDrop.org engine suite

“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

1. The sender hashes each 64 KiB chunk into a running SHA-256 as it reads and sends it.
2. The receiver hashes the same chunks as it writes them to their destination.
3. After the last chunk, the sender transmits its final digest.
4. 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.

Our 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 SHA256

Identical 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.

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 our 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.