Hashing vs encryption vs encoding
These three are often confused but solve different problems. Encoding (like Base64) is reversible by anyone and protects nothing — it just reshapes data. Encryption is reversible by someone holding the key. Hashing is deliberately one-way: there is no key and no way back from digest to input. That’s why hashes are used for integrity checks and password storage, never for hiding data you’ll need to read again.
Algorithm comparison
| Algorithm | Digest size | Status | Appropriate uses |
|---|---|---|---|
| MD5 | 128-bit | Broken (collisions) | Legacy checksums, cache keys |
| SHA-1 | 160-bit | Broken (collisions, 2017) | Legacy Git objects, old protocols |
| SHA-256 | 256-bit | Secure | File integrity, signatures, general use |
| SHA-512 | 512-bit | Secure | Same as SHA-256; faster on 64-bit CPUs |
“Broken” means researchers can construct two different inputs with the same digest — fatal for signatures, irrelevant for detecting a corrupted download from a trusted mirror.
A practical integrity-check workflow
When a download page publishes a checksum: download the file, hash it locally with the same algorithm, and compare your digest to the published one character by character (or paste both into the compare field). A mismatch means the file was corrupted in transit or tampered with — delete it and re-download, ideally from a different mirror. Publishing checksums alongside artifacts you distribute (releases, datasets, firmware) lets your users do the same.
Why password storage needs more than a hash
Plain SHA-256 is too fast for passwords: an attacker with a GPU can test billions of candidates per second against stolen digests. Password storage requires deliberately slow, salted algorithms — bcrypt, scrypt, or Argon2 — where each guess costs real time. Use the Bcrypt Generator on this site for that job, and reserve plain hashes for data integrity.