Verify downloads and file integrity with checksums

A cryptographic hash turns any input into a fixed-length fingerprint. Flip one bit anywhere in a gigabyte file and the digest changes completely, so comparing digests is a precise test of whether two copies of a file are byte-identical.

• Integrity provenIntegrity is proven: if your digest matches the published one, your copy is exactly the file the publisher hashed, with no corruption in transit or on disk.
• Authenticity separateAuthenticity is not: a checksum printed next to the download says nothing about who wrote the file—an attacker who replaces the download can replace the printed checksum too.
• Signatures are another toolAuthenticity needs a different mechanism: a signature verified against a key you already trust, or a checksum delivered through a channel you trust more than the download itself.

MD5 produces a 128-bit digest written as 32 hexadecimal characters; SHA-1 produces 160 bits as 40 characters. Both are fast and fine for spotting accidental corruption—and both have publicly demonstrated collisions, so neither resists an attacker crafting a malicious file with a matching digest.

The practical rule: an MD5 or SHA-1 match still catches a truncated download or a failing disk, because accidents do not compute collisions. What those algorithms cannot do anymore is clear a file you have reason to distrust—that judgment now belongs to SHA-256 or better.

• MD5 is brokenMD5 collisions have been practical for years: two different files with the same MD5 digest can be constructed deliberately, so MD5 can no longer distinguish accident from attack.
• SHA-1 is brokenSHA-1 followed the same road: a demonstrated collision ended its life as a security primitive, and browsers, certificate authorities, and code hosts have all moved on.
• SHA-2 is the baselineThe SHA-2 family is the current baseline: SHA-256 (64 hex characters) is the default for published download checksums, with SHA-224, SHA-384, and SHA-512 (56, 96, and 128 characters) as siblings for different constraints.

The whole check takes under a minute and uses tools already on your machine. The sequence matters: get the expected digest from the publisher’s official page, hash your local copy, and compare every character.

A mismatch is not always malice—truncated downloads and caching proxies corrupt files routinely—but the response is the same either way: the file fails verification, and the only correct next step is a fresh copy from the source.

• Get the expected valueFind the published checksum on the vendor’s official download or release page—ideally over HTTPS on a domain you navigated to yourself, not a mirror or a search-result snippet.
• Hash locallyHash the downloaded file locally: shasum -a 256 on macOS or Linux, or Get-FileHash in PowerShell on Windows. Both run against your disk; nothing is uploaded.
• Compare exactlyCompare the full digest character by character, case-insensitively. A single different character means discard the file and fetch a fresh copy from the source—do not install it and hope.

Many real checks are text, not files: a configuration snippet, a license key, a token fragment, a value a colleague dictated over the phone. Pasting those into a random website hands them to someone else’s logs, so the hashing has to happen locally.

SHA-256 Hash & Verify covers the 64-character current standard for published checksums. Verification there is comparison, not decryption: your text is hashed, and the two values are compared inside the browser.

• Local by designInput stays on the device: the workspace hashes up to 1,048,576 bytes of UTF-8 text in the tab with a WebAssembly engine, and retains nothing afterwards.
• Explicit comparisonVerify mode is an explicit comparison: paste the expected digest and the workspace reports match or mismatch, rejecting malformed values up front—exactly 32 hex characters for MD5, 64 for SHA-256.
• One-way by constructionDigests are one-way: these tools create and compare fingerprints and will not attempt to reverse one, because no legitimate tool can.

Checksums only work when comparing them is a habit rather than an afterthought. A few small disciplines make the check reliable every time.

For whole files, the operating system’s built-in commands are the right tool and are just as local as the browser. The browser workspaces shine for text payloads and quick digest checks—MD5 Hash & Verify for the legacy 32-character references that older download pages still publish.

• Full comparisonCompare the entire digest, not the first and last few characters; a partial eyeball is exactly the shortcut a crafted collision exploits.
• Name the algorithmKeep the algorithm name with the digest: 64 hex characters could come from several algorithms, and a checksum without its label invites guessing.
• Re-hash per hopRe-hash after moving a file through USB drives, sync clients, or email; each hop is a new chance for corruption, and the digest travels free.

If you distribute files—a release binary, a dataset, an internal tool—publish checksums alongside them. It costs one command per artifact and gives every recipient a way to verify integrity without contacting you.

SHA-512 Hash & Verify produces the 128-character digest locally when you need the longer form, and the SHA-224 and SHA-384 siblings cover the rest of the SHA-2 family—same engine, same tab, same boundary.

• SHA-256 minimumPublish SHA-256 at minimum; add SHA-512 alongside when your audience verifies on platforms where it runs faster, and label each digest with its algorithm.
• Same trust levelServe the checksums from the same trust level as the download itself, ideally from a page or repository your users already consider authoritative.
• MD5 as legacy labelKeep MD5 lines only as legacy compatibility labels, clearly marked as integrity checks for accidental corruption—never as security verification.