SHA Hash Generator & File Checksum

What a hash is

A one-way fingerprint. Any input, three characters or a three-gigabyte file. Produces a fixed-length output. The same input always gives the same hash, and changing anything at all changes the hash completely.

That last property is the useful one. There's no "close". A one-byte difference produces an entirely unrelated result, so a corrupted download is immediately obvious rather than subtly wrong.

Verifying a download, properly

When a project publishes a checksum next to a download link, this is what it's for:

1. Download the file.
2. Hash it here with the algorithm the publisher used, usually SHA-256.
3. Paste their published checksum into the compare box.
4. A match means your copy is byte-identical to what they released.

A mismatch means one of two things: the download was corrupted in transit, or the file isn't what the publisher released. Either way, don't run it, download again from the official source and check once more.

One caveat worth understanding: this only proves the file matches that checksum. If an attacker controls the page, they can change both the file and the checksum. The protection is real when the checksum comes from somewhere the file doesn't, a signed release note, a separate domain, a package manager's own index.

Why MD5 and SHA-1 aren't offered for new work

Both are broken for security purposes. Researchers have demonstrated practical collisions: two different files producing the same hash. MD5 collisions can be generated in seconds; SHA-1's were demonstrated in 2017 and have got cheaper since.

That destroys the guarantee. If two files can share a hash, a matching hash no longer proves you have the right file. SHA-1 is included here only because you may need to check against an old published value; don't use it for anything new.

Algorithm	Output	Status
MD5	128 bits	Broken, not offered
SHA-1	160 bits	Broken, legacy checks only
SHA-256	256 bits	Recommended
SHA-384	384 bits	Fine
SHA-512	512 bits	Fine, and often faster on 64-bit hardware

Hashing is not encryption

They get confused constantly, and the difference is fundamental.

Encryption is reversible: that's the point. With the key you get the original back. If you want that, use the text encryption tool.

Hashing is one-way. There is no key and no way back. It's for verifying, not for hiding something you'll need to read later.

Why passwords need more than a hash

Hashing a password with SHA-256 seems reasonable and isn't. SHA is designed to be fast, which is exactly wrong for passwords: an attacker with a leaked database can compute billions of guesses per second and check them all.

Password storage needs a deliberately slow, salted function, bcrypt, scrypt or Argon2. Slow so guessing is expensive, salted so each password must be attacked individually rather than all at once with a precomputed table.

If you're building something that stores passwords, use a library that does this. It is not a place to improvise.

Other things hashes are used for

• Deduplication: two files with the same hash are almost certainly the same file.
• Integrity monitoring: hash the important files, re-hash later, see what changed.
• Version control: Git identifies every commit and file by its hash.
• Subresource integrity: the integrity attribute on a script tag, so the browser refuses a CDN file that doesn't match.
• Blockchains: chaining blocks by hash is what makes history tamper-evident.