What Is a Hash? (And When Not to Use One)

The one-way function

A hash takes any input — a sentence, a file, a password — and produces a fixed-size output. SHA-256 always returns 64 hex characters. The defining property is that it is one-way: given the hash, you cannot recover the input. Change one character and the whole hash changes, which makes hashes excellent for detecting change and terrible as a storage format for anything you need back.

Three common jobs

Checksums (SHA-256, CRC32). Download a file, hash it locally, and compare to the hash the publisher printed. If they match, the file arrived intact. CRC32 is weaker but faster, useful for casual corruption checks.

Password storage (not plain SHA-256). For passwords you need a slow, salted function — bcrypt, argon2 or scrypt. Fast hashes like SHA-256 let attackers brute-force billions of guesses per second on a GPU. This is a case where choosing the "modern-looking" algorithm is a security mistake.

Deduplication and indexing (MD5, CRC32). Identifying duplicate content or sharding keys uses hashes for speed, not security. MD5's collisions don't matter here.

Why a hash is not encryption

Encryption is reversible with a key. Hashing is not reversible at all. The two get confused because both produce opaque strings, but treating a hash as encrypted data — or "decrypting" a hash — is impossible by design. If a service claims to decrypt hashes, it is almost certainly guessing inputs against a lookup table, which is why unique, salted values matter.

A cheat sheet for choosing

• Integrity check of a downloaded file → SHA-256 (or SHA-512 for extra margin).
• Quick corruption scan over a local backup set → CRC32 or SHA-1 for speed; collisions are irrelevant here.
• Deduplicating content or building a lookup key → MD5 or SHA-256; only distribution matters.
• Storing a password → do not roll your own. Use bcrypt, argon2id or scrypt with a per-user salt; libraries exist for every language.
• Signing a message → not a plain hash. Use an HMAC (keyed hash) or a proper signature scheme.

Why "salted" changes everything

A hash alone cannot hide a weak password: an attacker hashes a dictionary of common passwords and matches the results — that is why unsalted MD5 password leaks get cracked so quickly. A random salt per user makes each hash unique, so the same password stored twice produces two different hashes and the attacker must crack each one individually. Slow, memory-hard functions (argon2id, scrypt) then raise the cost per guess by orders of magnitude. If you are reading this before writing a password system, those two properties — per-user salt plus a slow algorithm — are the minimum.

Try it locally

Open ToolsKit's hash generator and watch how password and Password produce completely different SHA-256 values — then hash the same string twice to confirm it is deterministic. That determinism plus one-way-ness is the whole superpower.