What a hash actually proves
Hash functions like MD5, SHA-256, and SHA-512 take an input of any size and reduce it to a short, fixed-length string of hex characters (32 characters for MD5, 64 for SHA-256, 128 for SHA-512). Publishers list this value alongside a download so that anyone can independently recompute it and confirm the file arrived exactly as intended — no dropped packets, no tampering, no silent corruption from a flaky connection.
It's important to be clear about the limits here: a hash confirms integrity (the bits are unchanged), not authenticity (that a trusted party actually produced the file) unless the hash itself is delivered over a channel you trust, such as a signed release page. That distinction is exactly why HMAC exists, which we cover further down.
Verifying a downloaded file's integrity
In practice this is a three-step routine: find the hash the publisher lists (usually next to the download link, sometimes in a separate .sha256 file), open a hash tool and drop the downloaded file into it, then paste the published value into the comparison field. A tool that runs entirely client-side — using JavaScript for MD5 and the browser's built-in Web Crypto API for the SHA family — never uploads your file anywhere, so this works even for confidential documents.
Say, hypothetically, you download a 2.1 GB disk image and the vendor's page lists a SHA-256 value. In a slow or interrupted download, even one missing byte will produce a completely different digest — this is a made-up illustrative example, not a guaranteed real-world figure, but it shows why "close enough" doesn't apply to hashes: they either match exactly or they don't.
| Step | What you do | Result |
|---|---|---|
| 1 | Copy the SHA-256 from the publisher's page | e3b0c4...(64 hex chars) |
| 2 | Upload the downloaded file to the tool | Tool computes actual SHA-256 |
| 3 | Paste expected hash, compare | Match → file intact |
MD5 vs SHA-256 vs SHA-512 — which one to trust
The core tradeoff is speed versus security guarantees. MD5 (128-bit digest) and SHA-1 (160-bit digest) are both old enough that deliberate collisions — two different inputs producing the same hash — have been demonstrated, which rules them out for passwords, digital signatures, or anything an attacker might want to forge. They're still perfectly reasonable for catching accidental corruption, like a truncated download.
- MD5 — 32 hex chars, very fast, use only for non-security checksums.
- SHA-1 — 40 hex chars, legacy compatibility only, weak.
- SHA-256 — 64 hex chars, today's general-purpose default, used in TLS certs.
- SHA-384 / SHA-512 — 96 / 128 hex chars, larger security margin, common in high-assurance systems.
Beyond plain hashing: HMAC and SRI
If you're verifying a webhook payload from a payment processor or automation platform, a plain hash isn't enough, because anyone can compute a SHA-256 of a message. HMAC-SHA256 requires a shared secret key, so only someone who holds that key could have produced the matching signature — that's the difference between "the data wasn't corrupted" and "this really came from the party who holds the secret."
integrity="sha384-..." attribute on a <script> or <link> tag tell the browser to hash a CDN-hosted file before running it, and refuse to execute it if the hash doesn't match — protecting a site if the CDN is ever compromised.Generating an SRI hash follows the same underlying math as any other hash, just with the output formatted as Base64 and wrapped in the algorithm-prefixed tag format browsers expect (sha256-, sha384-, or sha512-). If you paste in the exact content of a script or stylesheet file, a hash tool with an SRI mode can build the ready-to-use tag for you directly.