Computing File Hashes with MD5, SHA-1, and SHA-256: A Practical Guide

A file hash is a short fingerprint of a file's exact bytes. Feed the same bytes in, and you always get the same fingerprint out. Change one byte, and the fingerprint changes completely. That single property is why hashes show up everywhere people care whether a file is intact: software releases, backups, firmware downloads, legal evidence, and audit trails.

This guide walks through what the common hash algorithms actually do, how to verify a download against a published checksum, why a hash catches tampering that the eye cannot, and why none of this needs to leave your machine.

What a file hash actually is

A hash function reads every byte of a file and produces a fixed-length string regardless of the input size. A one-line text file and a 4 GB disk image both come out the same length for a given algorithm. The output is usually written in hexadecimal.

The three names you will meet most often:

• MD5 produces a 128-bit digest, written as 32 hex characters. It is fast and still common for casual "did this transfer correctly" checks, but it is broken for security: attackers can craft two different files with the same MD5. Treat it as a typo detector, not a tamper detector.
• SHA-1 produces a 160-bit digest, 40 hex characters. It is also considered broken for collision resistance and is being retired across the industry.
• SHA-256 produces a 256-bit digest, exactly 64 hex characters. It is the current default for integrity and signing work, with no practical collision attack known.

Here is the concrete part worth remembering: SHA-256 always produces 64 hex characters, and flipping even a single bit anywhere in the file changes roughly half of those characters. There is no "small change makes a small difference" behavior. The output looks completely unrelated, which is exactly what you want from a tamper signal.

Verifying a download against a published checksum

This is the everyday use case. A project publishes a release file alongside its expected hash. You download both, compute the hash of what landed on your disk, and compare.

Say you download toolkit-2.4.0.tar.gz, and the project's release page lists:

SHA-256: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

You compute the SHA-256 of your downloaded file and read back:

9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Character for character identical, so the file you hold is byte-for-byte the file the maintainers built. If even one character differs, stop. The download was corrupted in transit, truncated, or swapped for something else. Do not run it.

To do this without command-line tools, drop the downloaded file into the File Hash Calculator, pick SHA-256, and paste the published value next to the computed one. The comparison takes a few seconds and you never have to remember the exact flag order for shasum or certutil.

Why a hash detects tampering the eye misses

Two files can look identical and be completely different. A signed installer and a malicious clone can share an icon, a filename, a version string, and even an identical file size if the attacker pads to match. None of that is the bytes.

A hash reads the bytes. Append a single hidden instruction to a script, swap one library inside an archive, or flip a flag in a binary, and the SHA-256 lands somewhere entirely different from the published value. There is nowhere to hide a change, because the function depends on every byte equally.

The flip side matters too: a hash only proves equality. It does not prove the file is safe or that the source was honest. If an attacker controls both the file and the checksum page, matching hashes mean nothing. That is why serious distribution pairs the hash with a signature, and why you should pull the expected checksum from a trustworthy channel, not the same link that served the file.

One more gotcha I see constantly: a hash changes when a file is re-saved, even if the visible content looks the same. Re-exporting a PDF, re-zipping a folder with a different compression level, or saving a document with a new timestamp all shift the bytes and therefore the digest. A mismatch does not always mean malice. Sometimes it just means the file went through a tool that rewrote it.

A note from my own workflow

I started hashing files seriously after a release went out with a quietly corrupted archive. Two of us had downloaded the same tarball from the same link; mine extracted cleanly and theirs threw a checksum error halfway through a build. We had no shared reference point, so we spent an afternoon arguing about whose network was at fault.

Now the rule on my side is boring and reliable. Every artifact that ships gets a SHA-256 recorded in the release notes at build time. When someone reports a problem, the first question is always the same: what hash did your copy produce? Nine times out of ten the digests match and the bug is real. The tenth time, the digests differ and the conversation is over in thirty seconds. That one habit has saved more hours than any debugging trick I know.

Why local hashing is the right default

Computing a hash does not require sending the file anywhere. Every modern browser ships the Web Crypto API, which can read the bytes of a file you select and produce a SHA-256, SHA-384, or SHA-512 digest entirely on your own device. The file never travels to a server.

That matters for two reasons. First, privacy and policy: you should not be uploading firmware images, customer backups, or legal evidence to an unknown service just to get a fingerprint. Second, trust: if a remote service computes the hash, you are trusting it to compute honestly. Local hashing removes the middleman, and you can confirm the page works offline. The File Hash Calculator does exactly this, hashing in the tab and exporting a CSV of filename, size, and digest for batches. If your next step is encoding a small file for transport rather than fingerprinting it, the File to Base64 Converter runs the same way, locally in the browser.

Putting it together

Pick the right algorithm for the job. Use SHA-256 as your default for anything that touches integrity or security, keep SHA-512 for extra margin, and reserve MD5 and SHA-1 for legacy compatibility only. Always pull the expected checksum from a source you trust, compare it character by character, and remember that a clean match proves the bytes are identical, not that the file is safe. Do the work locally, record the digests you publish, and you turn a vague "I think the download is fine" into a fact you can check in seconds.

---

Made by Toolora · Updated 2026-06-13