Just File Tools

How to verify a download is genuine with SHA-256 (and why MD5 is not enough)

Checking a download against a published SHA-256 hash catches both corruption and tampering. Here is the workflow, and why MD5 only catches the first one.

Uses tool: File Hash Verifier

When you download a Linux ISO, an installer, a cryptocurrency wallet, or any other software-distribution file, the project's website usually lists a "checksum" or "hash" next to the download link. The recommended workflow: compute the hash of your downloaded file and compare it to the published one. If they match, your file is byte-identical to what the project published. If they don't match, somewhere along the way the bytes changed — download corruption, malicious mirror, or something else worth investigating.

Why two different files have different hashes

A cryptographic hash function takes any input and produces a fixed-size output (e.g., SHA-256 always produces 256 bits = 64 hex characters). Two key properties:

  • Deterministic. The same input always produces the same hash. Compute the SHA-256 of the same file twice and you get the same 64-character string both times.
  • Avalanche. Changing one bit of the input changes roughly half the bits of the output. Two files differing by even one byte have completely different hashes. There's no way to construct a different file with the same hash by guessing or by manipulating individual bytes.

These properties make hashes great fingerprints. If your downloaded file produces the same hash as the published one, the bytes match. If not, something is different.

SHA-256 vs MD5

Older download pages still list MD5 hashes. MD5 has been cryptographically broken since 2008 — researchers can construct two different files with the same MD5 hash. For integrity (catching download corruption), MD5 still works fine; random bit flips will not coincidentally produce the same MD5. For authenticity (proving the file is what was published, even against an adversary who can choose the bytes), MD5 is broken.

SHA-1 is also broken (Google demonstrated a collision in 2017). SHA-256 is not broken — no published technique can produce collisions in SHA-256. For new verification workflows, SHA-256 (or SHA-512 for extra margin) is the right choice. When a project publishes only MD5, you can verify that the bytes match what they published, but you can't verify that nobody tampered with the published hash itself.

Step-by-step with our tool

  1. Download the file you want to verify.
  2. Find the published hash on the project's release page or signature file. It's usually a 40-character (SHA-1), 64-character (SHA-256), or 128-character (SHA-512) hex string.
  3. Open justfiletools.com/tools/file-hash.
  4. Drop the downloaded file onto the page.
  5. The tool computes SHA-256 first, then SHA-1, SHA-512, SHA-384, and MD5. Each appears as it completes.
  6. Paste the published hash into the "Compare against an expected hash" field.
  7. If the published hash matches any of the computed hashes, that row glows green with a "Match" badge.

Reading "checksums" files

Many projects publish a separate SHA256SUMS or CHECKSUMS file alongside the downloads. The format is one hash per file: 

e8b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  ubuntu-22.04-desktop-amd64.iso
3d4f5e1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e  ubuntu-22.04-server-amd64.iso

The hash and filename are separated by whitespace. Some formats add an asterisk (*filename) to indicate binary mode. Our tool accepts pasting this whole line — it extracts the leading hex run and ignores everything after.

The full verification workflow for serious software

Hash verification is one step in a fuller authentication workflow:

  1. Verify the published hash itself. Look at the project's website over HTTPS (so a network attacker can't tamper with the hash before you see it). Or use the project's signed-checksums file, which is a checksums file signed with the project's GPG key.
  2. Verify the GPG signature. Download the SHA256SUMS.asc or SHA256SUMS.sig file alongside the checksums file. Run gpg --verify SHA256SUMS.asc. The signature proves the checksums file was produced by someone holding the project's signing key.
  3. Verify the project's signing key. The GPG key fingerprint should be published on the project's website, ideally also via independent channels (Twitter, mailing list archives, GitHub repo). The fingerprint should be the same across all channels.
  4. Compute the hash of your download. Use our tool, or sha256sum filename at a command line.
  5. Compare. The hash from your download should match the hash in the (now-trusted) checksums file.

Most users skip steps 2 and 3. For everyday software (a free utility, a game), that's fine. For high-stakes software (cryptocurrency wallets, system installers, security tools), do the full verification — the threat model is high enough.

Common pitfalls

Comparing the wrong hash. A project might publish SHA-256 but the file you're comparing against was hashed with SHA-1. Our tool computes all five common hashes so any match counts.

Case sensitivity. Hex strings are usually lowercase but can be uppercase. The comparison is case-insensitive — abc123 and ABC123 match.

Whitespace in the pasted hash. Tolerated. The tool extracts the first contiguous hex run from whatever you paste.

"Verified" means more than it does. A matching hash proves the bytes you have match the bytes the publisher signed. It does not prove the publisher's intentions, the absence of bugs, or the absence of intentional malware. It only proves byte equality.

Alternative approaches

  • sha256sum / shasum at the command line. Free, fast, ships with every Linux/macOS install. shasum -a 256 file.iso on macOS, sha256sum file.iso on Linux.
  • certutil on Windows. Built-in tool. certutil -hashfile file.iso SHA256. Verbose output but works.
  • HashTab for Windows. Free, adds a Hashes tab to the file Properties dialog. Convenient for repeated verifications.
  • Online verification services. Upload-based. Wrong tradeoff for installer files (they may be very large) and unnecessary if you trust the command-line tools.

Privacy considerations

The file hash is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest) plus spark-md5 for MD5. The file's bytes are read by the File API into your browser's memory, hashed by JavaScript / WebAssembly locally, and the hex digest is displayed in your tab. No upload. The file never crosses the network.

This matters for files you can't or shouldn't upload — internal release builds, work documents, password databases, encryption keys. The same workflow works for all of them: compute the hash locally, compare to the expected hash, no third party involved.

Related tools and guides

Try it now: File Hash Verifier

Compute MD5/SHA hashes of any file and verify against an expected value

Open File Hash Verifier