Hash Generator

What a hash is for

A hash function turns input of any length into a fixed-length fingerprint. The same input always produces the same digest, and any change to the input — a single flipped bit — produces a completely different one.

That property makes hashes useful for integrity checking. A project publishes the SHA-256 of its installer; you hash your download and compare. If they match, your copy is byte-identical to what was published. If they do not, something went wrong in transit, or the file is not what it claims to be.

Hashing is one-way. You cannot reconstruct the input from the digest, which is what separates it from encoding schemes such as Base64. What you can do, if the input space is small, is hash every candidate and look for a match — which is exactly why hashing passwords with a plain SHA function is inadequate.

Which algorithm to use

SHA-256 is the right default for anything new. It is widely supported, has no known practical weaknesses, and is what most projects publish checksums in.

SHA-512 is not meaningfully more secure for most purposes but is faster than SHA-256 on 64-bit hardware. Use it if something specifies it.

SHA-1 is cryptographically broken — a practical collision was demonstrated in 2017 — and should not be used where an adversary might try to forge a match. It remains fine for non-adversarial integrity checks and still appears widely in legacy systems and in Git.

MD5 is thoroughly broken and collisions can be generated in seconds. It is nonetheless still published as a download checksum by many projects, and for catching accidental corruption it remains perfectly serviceable. Because the Web Crypto API deliberately omits it, this tool includes its own implementation so those checksums can still be verified.

Verifying a download properly

Drop the file into the box and compare the digest to the published one. The comparison is exact: hashes match completely or not at all, so there is no such thing as being close.

The file is read locally by your browser, which matters practically as much as it does for privacy — uploading a four-gigabyte ISO to a hashing website to verify it would be absurd, and yet server-side tools require exactly that.

One caveat about what verification proves. Matching the checksum on the same page as the download only tells you the file arrived intact; if an attacker controlled the page, they controlled both. Real assurance comes from a checksum published somewhere independent, or better, from a signature you can verify against a known key.

Do not hash passwords this way

A general-purpose hash function is designed to be fast, and speed is precisely the wrong property for password storage. Modern hardware computes billions of SHA-256 hashes per second, which makes brute-forcing a stolen database of them entirely practical.

Password hashing needs a function that is deliberately slow and memory-hard: Argon2id is the current recommendation, with bcrypt and scrypt as established alternatives. All of them incorporate a per-password salt, so identical passwords do not produce identical hashes, and a tunable cost factor that can be raised as hardware improves.

Use this tool for integrity checking, deduplication, and generating identifiers. Not for storing credentials.