Hashing Explained: MD5, SHA-256 and When to Use Them

Hashing sits behind a surprising amount of everyday technology — from checking that a downloaded file isn't corrupted to storing passwords safely. The terms (MD5, SHA-256, "checksum") sound intimidating, but the core idea is elegant and easy to grasp. This guide explains what hashing is, how it differs from encryption, and which algorithm to reach for.

What a hash function does

A hash function takes any input — a word, a document, an entire disk image — and produces a fixed-length string of characters called a hash or digest. The same input always produces the same hash, but even a tiny change to the input (a single letter) produces a completely different hash. Crucially, the process is one-way: you cannot reverse a hash back into the original data.

Think of it as a digital fingerprint. Two identical files share a fingerprint; two different files almost never do; and you can't reconstruct a person from their fingerprint.

Hashing is not encryption

This trips people up constantly. Encryption is reversible by design — with the right key, encrypted data turns back into the original. Hashing is deliberately not reversible; there is no key and no "unhash" operation. Encryption is for keeping data secret and then getting it back. Hashing is for verifying integrity and identity without ever needing the original back.

Two everyday uses

• File integrity. When you download software, the publisher often lists its hash. Hash the file you received and compare: if the fingerprints match, the file arrived intact and untampered. If they differ, something changed in transit.
• Password storage. Well-built systems never store your actual password. They store a hash of it. When you log in, they hash what you typed and compare hashes. Even if the database is stolen, attackers get fingerprints, not passwords — provided the hashing was done properly.

Why MD5 (and SHA-1) are broken

MD5 was once everywhere, but it is now considered broken for security. Researchers found ways to produce "collisions" — two different inputs that yield the same hash — which destroys the guarantee that a fingerprint is unique. SHA-1 has fallen the same way. Both are still occasionally fine as quick, non-security checksums to spot accidental corruption, but you should never rely on them where security matters.

Where SHA-256 fits

SHA-256, part of the SHA-2 family, is the modern default for general-purpose secure hashing. It has no known practical collisions and is widely trusted for file verification and digital signatures. One nuance: for passwords specifically, even SHA-256 on its own is too fast — attackers can try billions of guesses per second. Password storage should use a deliberately slow, salted algorithm designed for the job (such as bcrypt, scrypt or Argon2). SHA-256 is excellent for verifying files; password hashing is a specialised case.

Trying it out

The best way to build intuition is to experiment. Our hash generator computes MD5, SHA-1, SHA-256 and more from any text, right in your browser — change one character and watch the entire hash change. If you're thinking about passwords, pair this with a strong password generator and a manager rather than relying on hashing alone.

Salting: the missing ingredient for passwords

There's one more concept that makes password hashing safe: the salt. If two people choose the same password, a plain hash of it would be identical — which lets attackers build giant pre-computed tables ("rainbow tables") mapping common passwords to their hashes. A salt is a unique random value added to each password before hashing. Because every user gets a different salt, identical passwords produce different hashes, and pre-computed tables become useless. Proper password algorithms like bcrypt, scrypt and Argon2 handle salting automatically and are also deliberately slow, so an attacker who steals the database can only test a few guesses per second instead of billions. This combination — slow plus salted — is what separates safe password storage from the fast, unsalted hashing that's fine for file checksums but dangerous for passwords.

Checksums in everyday life

Hashing quietly protects you far more often than you notice. Software downloads publish checksums so you can confirm a file wasn't corrupted or tampered with. Version-control systems like Git identify every saved change by its hash. Data-storage systems use hashes to detect silent corruption on disk. In each case the same simple property is doing the work: the same input always yields the same fingerprint, and any change — accidental or malicious — produces a completely different one.

That single property — deterministic, one-way, and exquisitely sensitive to change — is why hashing shows up in so many unrelated places. Whether it's confirming a download arrived intact, letting a login system check your password without ever storing it, or letting a version-control system name a snapshot of your work, the underlying trick is identical. Once the idea clicks, you start recognising it everywhere technology needs to answer the question "is this exactly the thing I expected, and has it changed?"

Key takeaways

• A hash is a one-way fixed-length fingerprint of data; you can't reverse it.
• Hashing verifies integrity and identity; encryption keeps data secret and reversible.
• MD5 and SHA-1 are broken for security — use SHA-256 for general secure hashing.
• Passwords need a slow, salted algorithm (bcrypt/scrypt/Argon2), not plain SHA-256.