Verify downloads and file integrity with checksums

A cryptographic hash turns input into a fixed-length fingerprint. Even a one-bit change is overwhelmingly likely to change the digest, so a trusted modern digest is strong evidence that two file copies have the same bytes.

• Integrity evidenceA trusted SHA-256 digest match is strong evidence that your copy has the same bytes as the publisher’s file; it does not prove who published it.
• 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 designText is hashed as UTF-8 without normalization (1 MiB). Files are hashed as original bytes in 1 MiB chunks (256 MiB limit), including empty files. A digest match does not authenticate its source; MD5 and SHA-1 are unsuitable for adversarial integrity checks. Processing runs in a cancellable local Worker with a 15-second execution budget.
• 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 constructionA digest cannot be decrypted, but short or predictable inputs can be guessed and hashed again. Do not use an unsalted general-purpose hash to protect passwords or other low-entropy secrets.

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

Create or compare a hexadecimal digest from UTF-8 text or original file bytes. Verification compares digests of the selected input locally; it does not decrypt a digest or authenticate its source.

• Full comparisonCompare every character. Checking only a few characters weakens any digest check; MD5 and SHA-1 can also suffer full-digest collisions even when the entire value is compared.
• 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.