Hashes: fingerprints, not encryption

A hash function takes any input — a word, a file, a hard drive — and produces a fixed-size fingerprint. Same input, same fingerprint, every time. Change one letter and the fingerprint changes completely. And crucially, the process only runs one way: you cannot compute the input from the hash. That one-way property is what makes hashes useful, and it's also why 'decrypt this hash' is a request that doesn't make sense.

What each one is for

CRC32 is an error check, not security — it catches accidental corruption in downloads and archives, and it's fast. Anyone can forge a CRC32 on purpose. SHA-256 is today's workhorse: file integrity, digital signatures, certificate chains, blockchain — 256 bits of collision resistance that nobody has dented. SHA-512 is its bigger sibling, sometimes faster on 64-bit hardware. SHA-1 sits in the awkward middle: broken for security (real forged documents exist since 2017), still lingering in old systems like git's default object naming.

MD5 deserves its own sentence: collisions can be generated in seconds on ordinary hardware, and it has been considered dead for cryptographic purposes for two decades. That's why our tool doesn't offer it. If a system you're using demands MD5 for anything security-related, that's a finding, not a feature.

The password caveat

One thing none of these hashes should do: store passwords. Fast hashes are exactly wrong for that job — an attacker with a leaked database can test billions of SHA-256 guesses per second. Password storage uses deliberately slow, salted algorithms (bcrypt, scrypt, Argon2) designed to make each guess expensive. If you remember one distinction from this page: SHA-256 fingerprints data, Argon2 protects passwords.

Try the hash generator above: hash 'hello', then 'Hello'. The completely different outputs from a one-letter change — the avalanche effect — is the property everything else is built on.