Hashing explained: MD5, SHA-256 and why salting matters
One-way functions, broken algorithms and the salt that protects your password.
A hash function takes any input — a single byte, a password, a 4 GB
video — and produces a fixed-size string of characters called a digest. SHA-256
always returns 256 bits (64 hexadecimal characters), whether you feed it the word
hi or the complete works of Shakespeare. The magic isn’t the output size, though;
it’s that the function only runs in one direction. Given the input you can compute the digest
in microseconds, but given the digest you cannot recover the input. That one-way property is
what makes hashing useful almost everywhere in computing.
The five properties that make a hash useful
Not every function that scrambles data is a good hash. A cryptographic hash function is expected to satisfy all of the following:
Deterministic
The same input always yields the same digest. Hash a file today and a year from now and the result is identical.
Fast to compute
Producing a digest is cheap, so you can verify gigabytes of data quickly. (For passwords this speed becomes a liability — more below.)
Avalanche effect
Change one bit of input and roughly half the output bits flip. cat and bat produce digests with nothing in common.
Collision-resistant
It should be infeasible to find two different inputs that share a digest. Collisions exist mathematically, but finding one should be impractical.
Irreversible
There is no key and no decrypt step. The only way back to the input is to guess it and hash the guess.
What hashing is actually used for
Because a digest is a compact, tamper-evident fingerprint of data, hashes show up in far more places than password storage:
- File integrity and checksums. A download lists a SHA-256 digest; you hash the file you received and compare. If a single byte was corrupted or altered in transit, the digests won’t match.
- Deduplication. Backup systems and cloud storage hash each block of data and store identical blocks only once, using the digest as the lookup key.
- Password storage. Sites store a hash of your password rather than the password itself, so a database leak doesn’t immediately expose plaintext credentials.
- Digital signatures. Signing hashes a document first, then signs the small digest rather than the whole file — faster and just as secure.
- Git. Every commit, file and tree in Git is addressed by its hash. The commit ID you see is a digest of the commit’s contents, which is how Git detects any change.
You can experiment with all of these by running text or a value through our hash generator, which computes MD5, SHA-1, SHA-256 and SHA-512 digests in your browser so you can see the avalanche effect for yourself.
MD5 and SHA-1: still common, no longer safe
Two of the most familiar algorithms are also the two you should never rely on for security. Both MD5 (1992) and SHA-1 (1995) have been broken in practice: researchers can deliberately construct two different inputs that produce the same digest. MD5 collisions can be generated on a laptop in seconds; SHA-1 fell in 2017 when Google produced two distinct PDFs with an identical SHA-1 hash (the “SHAttered” attack). A broken collision-resistance property means an attacker can swap a malicious file for a legitimate one without changing its checksum — fatal for signatures and integrity checks.
| Algorithm | Digest size | Status | Use it for? |
|---|---|---|---|
| MD5 | 128-bit | Broken (collisions trivial) | Non-security checksums only |
| SHA-1 | 160-bit | Broken (collision demonstrated) | Avoid; legacy compatibility only |
| SHA-256 | 256-bit | Secure | General-purpose integrity, signatures |
| SHA-512 | 512-bit | Secure | High-assurance integrity |
MD5 is still fine for one narrow job — a quick, non-adversarial checksum to catch accidental corruption, where nobody is actively trying to forge a collision. For anything an attacker might target, reach for SHA-256 or stronger.
Hashing is not encryption
This trips up almost everyone. Encryption is reversible: it uses a key, and anyone with the right key can transform the ciphertext back into the original plaintext. The whole point is to get the data back later. Hashing has no key and no way back — the digest is a fingerprint, not a locked box. You never “de-hash” anything. So if a product claims it can recover your original password from its hash, either it isn’t really hashing, or it’s storing your password in a way it shouldn’t. When you only need to verify that two things match without ever reading the original, hashing is the right tool; when you need the original data back, you want encryption.
Why passwords need a salt and a slow hash
Storing a plain SHA-256 of a password seems safe — it’s irreversible, after all. But two weaknesses make a bare hash dangerous. First, hashing is deterministic, so identical passwords produce identical digests; an attacker who steals the database instantly sees which users share a password, and can match digests against rainbow tables (precomputed hashes of millions of common passwords). Second, SHA-256 is fast — modern hardware can test billions of guesses per second.
A salt fixes the first problem. It’s a unique random value generated per user
and stored alongside the hash; you hash the salt together with the password. Now two users
with the password hunter2 get completely different digests, and an attacker can’t
reuse a precomputed table — every account must be cracked individually. The slow part fixes
the second problem: instead of a single fast hash, password storage uses a
deliberately slow, memory-hard algorithm — bcrypt,
scrypt or Argon2 — with a tunable cost factor. Making each guess take
a quarter-second instead of a nanosecond turns a feasible brute-force attack into one that
would take centuries.
The takeaway: a hash is a one-way fingerprint, not a cipher. Use SHA-256 for integrity and signatures, treat MD5 and SHA-1 as broken for security, and never store a password as a plain hash — always add a unique salt and a slow algorithm built for the job.
Related tools: Hash generator · Password generator