What a hash actually is
A hash function takes an input of any size — a single word, a paragraph, a multi-gigabyte file — and produces a fixed-length string of characters called a digest. Feed it a sentence or an entire novel and you get back a digest the same length either way; feed it the same input twice and you get back the identical digest every time.
A cryptographic hash function has to satisfy three properties to be useful for security work:
- Deterministic. The same input always produces the same digest, on any machine, at any time. That's what makes a hash useful as a fingerprint — you can compare two digests instead of two whole files.
- One-way. Given a digest, there's no practical way to work backwards to the original input. The only realistic approach is to guess inputs and hash each one, checking for a match — there is no shortcut that reverses the maths.
- Collision-resistant. It should be computationally infeasible to find two different inputs that hash to the same digest. This is the property that breaks first when a hash function ages, as the rest of this guide covers.
The avalanche effect
A well-designed hash function is built so that changing even a single bit of the input scrambles the entire output — there is no partial credit, no visible relationship between similar inputs and their digests. This is called the avalanche effect, and it's what makes a hash useless for spotting "roughly similar" content; two inputs differing by one character produce digests that look completely unrelated.
Worked example
MD5 of hello is 5d41402abc4b2a76b9719d911017c592. Capitalise a single letter — "Hello" instead of "hello" — and the digest bears no resemblance to the original at all; not one character lines up, despite the inputs differing by a single bit in a single byte. That total unpredictability from a tiny change is the entire point: it means a digest can act as a reliable fingerprint for exact content, and any tampering, however small, is guaranteed to be visible as a completely different digest, never a "close" one.
The empty string is a useful edge case to see the same function at work with zero input bytes: MD5 of an empty string is d41d8cd98f00b204e9800998ecf8427e, and SHA-256 of an empty string is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Both are fixed, well-known values — every correct implementation of MD5 or SHA-256 anywhere produces exactly these digests for empty input, which is a quick way to sanity-check that a hashing library is wired up correctly.
MD5 and SHA-1: broken for security, fine for checksums
MD5 produces a 128-bit (32 hex character) digest and was the workhorse checksum algorithm of the 1990s and 2000s. It is now considered cryptographically broken: researchers can deliberately construct two different inputs that hash to the same MD5 digest — a "collision" — far faster than brute force would suggest, using known structural weaknesses in the algorithm rather than luck.
SHA-1, a 160-bit (40 hex character) digest, was meant to be MD5's more robust successor, but it eventually suffered the same fate. NIST formally deprecated SHA-1 for government use in 2011, and in February 2017 Google and CWI Amsterdam publicly demonstrated the SHAttered attack — two distinct PDF files, visually different, that produced an identical SHA-1 hash. That wasn't a theoretical proof; it was a working, reproducible collision, and it's why every major browser and certificate authority has since stopped accepting SHA-1 signatures.
A collision matters wherever a hash is being used to prove something wasn't tampered with — a digital signature, a certificate, a piece of code presented as unmodified. If two different inputs can share a hash, an attacker can potentially substitute a malicious file for a legitimate one without changing the digest anyone is checking. That is a genuine security failure, not a cosmetic one.
None of that makes MD5 or SHA-1 useless everywhere. Where the only goal is catching accidental corruption — verifying a large file downloaded intact, generating a compact cache key, deduplicating records where nobody is deliberately trying to force a match — a broken-for-security hash is still a perfectly serviceable, fast checksum. The distinction is whether anyone has an incentive to construct a collision on purpose. If not, MD5 is fine; if a hash needs to resist a deliberate adversary, it no longer is.
Worked example — comparing digest lengths
Hashing ToolHare gives MD5 254e2d48377c0b31364f5664efc48737 (32 hex characters, 128 bits) and SHA-256 4cac3c35b28b0b0005b5a48c29f2243eb0f221dc208826f1761758ffb304b4fc (64 hex characters, 256 bits). The SHA-256 digest is exactly twice as long in hex because it carries twice as many bits — that longer output is a big part of why brute-forcing a collision in SHA-256 is astronomically harder than in MD5.
SHA-256 today
SHA-256, part of the SHA-2 family, produces a 256-bit (64 hex character) digest and is the current default choice for security-sensitive hashing: TLS certificates, code signing, Git commit integrity (increasingly), blockchain proof-of-work, and general-purpose data integrity checks. No practical collision attack against SHA-2 is known, and its much larger output space compared to MD5 or SHA-1 makes the kind of engineered collision that broke SHA-1 vastly harder to pull off. When a project needs "a secure hash" with no other special requirement, SHA-256 is the reasonable default.
Hashing, encryption and encoding are three different things
These three terms get used loosely and interchangeably, but they do genuinely different jobs:
- Hashing is one-way. There is no key, and the goal is a fixed-length fingerprint you can compare, never something you decode back to the original.
- Encryption is two-way, but only with the right key. The goal is confidentiality — scrambling data so it's unreadable to anyone without the key, and perfectly recoverable to anyone with it.
- Encoding — Base64 is the classic example — is two-way and needs no key at all. The goal is representing data in a different, more portable format, with zero attempt at secrecy; anyone can decode it. See our Base64 guide for the mechanics.
Mixing these up causes real mistakes: "hashing" a file to hide its contents doesn't work, because a hash discards the ability to recover the original entirely, by design; "encrypting" a password with a fast, general-purpose hash instead of a purpose-built password hash creates the exact weakness the next section covers.
Why passwords need slow, salted hashing — not MD5 or SHA-256
SHA-256 and MD5 are both designed to be fast, because their usual jobs — checksumming a file, signing a certificate — benefit from speed. That is exactly the wrong property for storing a password. If a database of password hashes leaks, an attacker doesn't need to reverse the hash mathematically; they just need to guess candidate passwords and hash each one, checking for a match. A single consumer GPU can compute billions of SHA-256 hashes per second, which turns "impossible to reverse" into "trivial to guess," for any password short or common enough to appear in a dictionary or a brute-force run.
Two further weaknesses compound the problem with a plain fast hash. Without a per-user random value (a salt) mixed into each password before hashing, identical passwords across different accounts produce identical digests, letting an attacker crack one and instantly know every account sharing it — and precomputed lookup tables ("rainbow tables") of common password hashes make cracking unsalted hashes faster still.
Purpose-built password-hashing algorithms — bcrypt, scrypt, and Argon2 (the current recommendation, and winner of the 2015 Password Hashing Competition) — solve this by being deliberately slow and memory-hungry, and by requiring a unique salt per password automatically. Slowing down a single verification by even a fraction of a second is invisible to a genuine user logging in once, but it multiplies an attacker's cracking cost by the same factor across billions of guesses. Never store a password with MD5, SHA-1, SHA-256 or SHA-512 alone, salted or not — those are the wrong tool for this specific job, however secure they are for the jobs they're actually designed for.
Frequently asked
Is a hash the same as encryption?
No. Encryption is reversible with the right key; hashing is one-way by design and was never meant to be reversed at all. If you need to get the original data back, you need encryption, not a hash.
Can two different files ever have the same hash?
In principle, yes — a fixed-length digest can only represent a finite number of values, while the number of possible inputs is unlimited, so collisions must exist mathematically. The question is whether anyone can find one deliberately in a feasible amount of time. For MD5 and SHA-1, yes, as SHAttered proved for SHA-1 in 2017. For SHA-256, no practical method is known.
Is MD5 safe to use for anything?
Yes, for non-security purposes where nobody has an incentive to force a collision — checking a download completed without corruption, a cache key, or deduplication. It is not safe anywhere a deliberate adversary might try to substitute one input for another undetected, such as digital signatures or password storage.
Why does this tool show MD5, SHA-1, SHA-256 and SHA-512 all at once?
Seeing the same input hashed by all four side by side makes the differences in digest length and value concrete, and it's practical if you need to check a hash of unknown algorithm against your own input. Try it on our hash generator, and read about our approach on how we build and verify our tools.