Checksums and hashes: how to verify a download with SHA-256

What a hash is

A hash function turns any amount of data, a word or a multi-gigabyte file, into a short string of fixed length: its hash, digest or checksum. Three properties make it useful. The same input always gives the same hash. Changing even one bit of the input gives a completely different hash. And going from the hash back to the input is, for practical purposes, impossible.

You can see the second property with two tiny inputs that differ by one letter. The SHA-256 of hello is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, and the SHA-256 of Hello is 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. They share nothing recognisable. The hash of empty input, in SHA-256, is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855; a handy value to recognise when a "file" turns out to be empty.

How to verify a download

Many projects publish a checksum next to the download link, so you can check the file arrived intact and was not swapped along the way. The routine:

1. Download the file, and copy the checksum the publisher lists (note which algorithm it is: the name is usually in the label, such as SHA256).
2. Open the hash generator and choose the file. It reads the file in your browser and never uploads it, which matters when the file is large or private.
3. Paste the published checksum into the comparison box. The tool tells you whether it matches one of the computed hashes.

If it matches, the file is what the publisher released. If it does not, the download was corrupted or altered and you should not use it: download it again, and if it still fails, be suspicious. One caveat: the checksum only proves the file matches the one the publisher posted. If the page where you read the checksum is the same page an attacker controls, both could be fake. That is why serious projects also sign their releases with a digital signature, and why you should take the checksum from the official site over HTTPS.

Which algorithm to use

A collision is two different inputs with the same hash. For MD5 and SHA-1, collisions can be manufactured, which means an attacker can prepare two different files with the same checksum. In February 2017, researchers at CWI Amsterdam and Google published the first real SHA-1 collision (the SHAttered project). NIST announced in 2022 that SHA-1 has reached the end of its useful life and should be phased out by 31 December 2030 in favour of SHA-2 and SHA-3. So: use SHA-256 by default, and use MD5 or SHA-1 only to compare against a legacy checksum or to spot accidental damage, never where an attacker could benefit.

Hashing is not encryption (and not for passwords)

A hash cannot be "decrypted", but short or common inputs can be guessed by trying many candidates and comparing hashes. That is exactly how attackers crack a stolen password database, and it is why a fast hash such as SHA-256 is the wrong tool for storing passwords: it is built to be quick, so an attacker can try enormous numbers of guesses per second.

The OWASP Password Storage Cheat Sheet says it directly: passwords must be protected using strong, slow hashing algorithms such as Argon2id, bcrypt or PBKDF2, with a unique salt per password, and fast hashing algorithms such as SHA-256 are not suitable for password storage. Its minimum recommendation is Argon2id with 19 MiB of memory, 2 iterations and a parallelism of 1. If you are building a login system, use a password-hashing library, not a bare hash. If you are choosing a password rather than storing one, see how to create a strong password.

HMAC: a hash with a secret key

An HMAC mixes a secret key into the hash, so only someone who knows the key can produce or check it. It is what signs webhook payloads and API requests, for instance. The hash generator offers HMAC-SHA-256 and the other SHA-2 sizes when you tick the HMAC option and enter a key.

Small details that cause mismatches

• Text encoding. A hash is computed on bytes, not characters. The same text in UTF-8 and in another encoding gives different hashes. The tool hashes text as UTF-8.
• Invisible characters. A trailing newline or space changes the hash completely. When a checksum "does not match" for text, check for one.
• Case and format. Hex digits are case-insensitive, so ABC123 and abc123 are the same hash; compare them in one case.
• Wrong algorithm. A 64-character hex string is probably SHA-256 (256 bits ÷ 4 bits per hex digit); 40 is SHA-1; 32 is MD5.

Sources and further reading

• NIST: NIST Retires SHA-1 Cryptographic Algorithm (December 2022)
• Google Online Security Blog: Announcing the first SHA1 collision (CWI Amsterdam and Google, 23 February 2017)
• OWASP: Password Storage Cheat Sheet

Figures checked on 3 October 2026.