How to Verify File Integrity During Transfer: SHA-256

Every few months, someone shares a horror story. A contractor delivers a 4GB video export to a client. Client downloads it, opens it — corrupt, half-rendered garbage. Nobody knows if the upload failed halfway, the file was the wrong version, or something glitched in the cloud. Hours get wasted re-exporting and re-sending.

That problem has a fast, permanent fix. It's called a checksum.

What File Integrity Actually Means

A file's integrity is binary: is this exact file — every bit — identical to what the sender originally shared?

Networks are imperfect. Files can be silently truncated during transfer. Cloud storage can have hardware glitches. Email gateways sometimes "sanitize" attachments in ways that corrupt binary files. And humans regularly upload the wrong version without noticing.

Integrity verification catches all of this. It answers a clear yes or no: did anything change?

This is separate from encryption — and it's worth being specific here. Encryption controls who can read a file. Integrity verification confirms whether the file changed. A password-protected link doesn't prove the file is unmodified; it just restricts access. As covered in why password protection isn't enough on its own, access controls and integrity verification solve different problems. You need both for a complete handoff.

SHA-256: The Practical Choice for File Fingerprinting

SHA-256 is a cryptographic hash function. Run any file through it and you get a 64-character hexadecimal string that's unique to that exact sequence of bits. Change a single character in a 500-page contract and the hash changes completely.

This is reliable in a way that older methods aren't. MD5 and SHA-1 are broken for this purpose — researchers have demonstrated collision attacks where two different files produce the same hash. SHA-256 doesn't have that problem for practical scenarios. Stick with it.

The commands are short and built into every major operating system.

macOS (Terminal):

shasum -a 256 path/to/file.ext

Linux (Terminal):

sha256sum path/to/file.ext

Windows (PowerShell):

Get-FileHash path\to\file.ext -Algorithm SHA256

You'll get back a 64-character hexadecimal string. That's the file's fingerprint. The same file always produces the same hash — it's deterministic. Keep the full value in your records, but you can share only the first 8-12 characters for a casual human check in chat.

The Handoff Workflow That Actually Works

Knowing the command is only half of it. The workflow matters just as much.

There's a common mistake: the sender uploads the file and includes the checksum in the same email or thread. If that channel is compromised — or if you accidentally paste a mismatched hash — the verification is worthless. The point is to send the checksum through a different channel from the download link.

Here's the protocol:

Prepare the file. Export the final version. Zip it if there are multiple items.
Compute SHA-256 and copy the full value.
Upload to your file sharing service.
Set access controls: password protection, expiry, download limits.
Send the download link via email.
Send the SHA-256 hash via a separate channel — Slack DM, SMS, Signal, anything distinct.
Recipient downloads, runs the same hash command, and compares the strings character by character.

If they match exactly, the file is intact. If they don't — stop. Don't open the file. Contact the sender, re-upload, and try again. A mismatch could be as innocent as a failed upload or as serious as a file substitution.

Encryption concept blocks spelling ENCRYPTION on a wooden surface

Labeling Clearly Prevents the Most Common Mistakes

Most integrity failures aren't attacks. They're human error. "final_report.pdf" and "final_report_revised.pdf" and "final_report_v3_FINAL.pdf" are different files. When you compute a hash, label it clearly.

A lightweight audit note alongside your project files takes 30 seconds:

final_deliverable_v4.zip
SHA-256: 3b4c8f9a1d2e...
Shared with: [email protected]
Sent via: Comfyfile (expires 2025-07-26, 3 download limit)
Checksum sent via: SMS

This has saved many hours of back-and-forth during disputes. It's especially valuable for lawyers who share confidential business documents, accountants delivering financial reports, and developers releasing software builds — any scenario where version integrity matters after the fact.

When to Use Lighter-Weight Checks

For casual transfers — a reference photo, a draft presentation for a colleague — full SHA-256 verification is overkill. But knowing what lighter alternatives actually guarantee is useful.

File size: The sender mentions "should be 34.7 MB" and the recipient checks before opening. Catches obvious truncation, not silent corruption.

Archive integrity: ZIP and RAR files have built-in checksums. A corrupt archive usually throws an error on open. Useful as a first pass — it checks archive structure, not file contents after extraction.

Code signing and GPG signatures: For software distribution or high-assurance document delivery, these go further. A GPG-signed checksum proves not just that the file is unchanged, but that you specifically confirmed it. This is how major open-source projects handle release tarballs. For most business file sharing it's more than you need — but if you're distributing installers or need non-repudiation on signed contracts, it's worth understanding.

Avoiding the Pitfalls That Bite Teams Regularly

Most verification failures come from a small set of recurring mistakes:

Comparing the wrong file. Verify the exact artifact you sent — the zip, not just one extracted file. If you re-export the same document five minutes later, the hash changes even if the content looks identical, because timestamp metadata gets embedded.

Mixing versions under the same filename. "final_v3.zip" should stay final. If you need to revise and re-share, compute a new hash and communicate clearly which version it corresponds to.

Sharing checksum and link in the same place. A README.txt inside the zip that contains the hash of the zip itself doesn't help — anyone who tampers with the zip can update the README. The checksum needs to travel separately.

Using weak algorithms. Avoid MD5 and SHA-1 for anything that matters. SHA-256 is the baseline. SHA-512 is fine too, though rarely necessary for file transfer verification.

Pairing Integrity Checks With Secure Sharing

A checksum proves the file wasn't corrupted or swapped. But it doesn't stop someone from forwarding the link to unauthorized parties, or downloading the file many times after the fact.

That's why access control and integrity verification are complementary. They cover different failure modes. The complete guide to secure file sharing covers both sides well — but the short version is: limit who can access the file, and independently verify what they received.

The file sharing mistakes that actually cause data leaks almost always involve one or the other failing. Either access wasn't controlled, or the recipient opened a file without confirming it was the right version.

A combined approach looks like this: upload to Comfyfile, add a password, set a 24-hour expiry, limit downloads to 1-3. Then text or direct-message the SHA-256 hash after the upload is confirmed. The recipient gets the link via email and the credentials plus hash via a separate channel — a short window to download, clearly traceable.

FAQ

Isn't a password enough?

No. A password controls access but doesn't prove the file didn't change. Use passwords for privacy and hashes for integrity. They're not interchangeable.

Do I verify after extracting a zip?

Verify the archive itself first. If you also need to verify individual extracted files, the sender needs to provide separate hashes for each file inside the archive.

What if the recipient's checksum doesn't match?

Assume the file changed or was corrupted. Re-upload and share a fresh link. If the mismatch persists across multiple attempts, try a different network or storage device — local disk issues sometimes cause this.

How long should I keep hash records?

As long as you'd keep the file itself. For contracts and regulated documents, that may mean years. For routine deliveries, a few weeks of project records is usually sufficient.

How Comfyfile Can Help

When you're handling the SHA-256 side manually, Comfyfile covers the access control side: upload your file, add a password, set a 24-hour expiry, and cap downloads at 1-3. Then send the hash through a separate channel so both pieces of verification stay independent. The recipient confirms what they received matches what you sent — and the link won't outlive its purpose.