Hash Generator

What a hash actually guarantees

A cryptographic hash maps any input to a fixed-length digest such that changing a single bit of the input changes roughly half the output bits, and such that finding two inputs with the same digest is computationally infeasible. That is what makes it useful for verifying a download: if the published SHA-256 matches yours, the bytes are the ones the publisher shipped.

It guarantees nothing about who published them. If an attacker controls the page showing the checksum as well as the file, both match perfectly. Checksums protect against corruption and mirror tampering, not against a compromised source — that is what signatures are for.

SHA-1 is here for reading old data, not for protecting new data

A practical collision against SHA-1 was demonstrated in 2017 (SHAttered), and a chosen-prefix collision followed in 2020. It must not be used for signatures, certificates or anything where an adversary chooses part of the input. It is still encountered in Git object IDs and legacy systems, which is the only reason it is included above.

Hashing a password is not the same as storing one

SHA-256 is designed to be fast, which is exactly wrong for passwords: a GPU rig can try billions of candidates per second. Password storage needs a deliberately slow, salted, memory-hard function — Argon2id, scrypt or bcrypt. If you are reaching for a hash to store user passwords, reach for one of those instead.

Whitespace is not invisible to a hash

The single most common “the checksum does not match” cause is a trailing newline that a text editor added, or a copied string with a leading space. The digest changes completely. When a published checksum disagrees, check the exact bytes before assuming the file is bad.

Frequently Asked Questions