Hashes: fingerprints, not encryption
What SHA-256 actually promises, why MD5 is dead, why CRC32 was never security, and which hash to use for which job.
By Noble Erne, LLC · 5 min read · Reviewed July 2026
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.
Published by Noble Erne, LLC. Enterprise systems consultant with a background in SAP implementation, software documentation, and instructional design. Builds the tools and writes the explainers on this site. Corrections to this guide go to the contact page and are reviewed before publication.
Related guides
- Base64: why binary data walks around dressed as text
What Base64 actually does, why it makes files 33% bigger, and the security mistake people keep making with it. - URL encoding: why spaces become %20
URLs have a strict guest list of allowed characters. How percent-encoding sneaks everything else in, and the double-encoding bug that eats query strings. - JSON: how a JavaScript accident won the data wars
Why JSON beat XML everywhere, the five syntax rules that cause every validation error, and where it genuinely falls short.