If you've ever downloaded a file and seen a strange string of letters and numbers labeled "checksum," or written code that stores a "hashed password," you've already run into MD5, SHA1, or SHA256 — probably without stopping to think about which one you actually needed, or why it mattered.
Here's the part most people miss: these three algorithms are not interchangeable, and two of them are considered broken for anything security-related. Picking the wrong one isn't just a technicality — it can be the difference between a system that's genuinely secure and one that only looks secure on the surface.
This guide breaks down what MD5, SHA1, and SHA256 actually do, where each one still makes sense in 2026, where they fail, and how to generate and compare them yourself.
What Is Hashing, Actually?
A hash function takes any input — a file, a password, a sentence, an entire database — and converts it into a fixed-length string of characters called a hash (or digest). No matter how big or small the input is, the output is always the same length for a given algorithm.
A good hash function has four core properties:
- Deterministic — the same input always produces the same output, every time.
- Fast to compute — generating a hash should take almost no time, even for large files.
- One-way — you cannot reverse a hash back into the original input.
- Collision-resistant — two different inputs should never, in practice, produce the same hash.
That last property — collision resistance — is exactly where MD5 and SHA1 fall apart, and it's the entire reason the "md5 vs sha1 vs sha256" comparison actually matters instead of being a purely academic exercise.
MD5: Fast, Familiar, and Broken for Security
MD5 (Message Digest Algorithm 5) produces a 128-bit hash, usually displayed as a 32-character hexadecimal string:
5d41402abc4b2a76b9719d911017c592
Why it became popular: MD5 is extremely fast to compute and was the default choice for checksums and basic data integrity checks for years, especially in the 1990s and 2000s.
The problem: Researchers have been able to deliberately engineer collisions — two completely different files that produce the exact same MD5 hash — since 2004. Once collisions can be manufactured on demand, checksums stop being trustworthy. An attacker could craft a malicious file that produces the same MD5 hash as a legitimate one, and your system would have no way to tell them apart.
Where MD5 is still fine to use:
- Detecting accidental file corruption during a transfer (not intentional tampering)
- Generating non-security cache keys or ETags
- De-duplicating uploaded files where no attacker is involved
Where MD5 should never be used:
- Password storage
- Digital signatures
- SSL/TLS certificates
- Any scenario where someone might deliberately try to forge a matching hash
You can generate an MD5 hash instantly using the MD5 Hash Generator — useful for quickly checking cache keys or verifying non-sensitive file integrity.
SHA1: An Improvement That Also Didn't Last
SHA1 (Secure Hash Algorithm 1) produces a 160-bit hash, shown as a 40-character hex string:
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
For a long stretch, SHA1 was the standard replacement for MD5. It's still used internally by Git to identify commits, and it was widely used in TLS certificates until relatively recently.
The problem: In 2017, Google and CWI Amsterdam publicly demonstrated a real-world SHA1 collision — the "SHAttered" attack — producing two different PDF files with identical SHA1 hashes. That confirmed what cryptographers had warned about for years: SHA1 can no longer be trusted for anything security-critical.
Where SHA1 still shows up:
- Git still uses SHA1 internally for commit hashes (some Git tooling is gradually migrating to SHA256)
- Legacy systems that haven't been updated yet
Where SHA1 should not be used:
- Certificates and code signing (major browsers and certificate authorities have deprecated it)
- Password hashing
- Any new system you're designing in 2026 — there's no good reason to pick SHA1 for something new
You can generate and inspect SHA1 hashes with the SHA1 Hash Generator if you're working with legacy systems or just want to compare output length and format against MD5 and SHA256.
SHA256: The Current Standard
SHA256 is part of the SHA-2 family and produces a 256-bit hash, shown as a 64-character hex string:
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
SHA256 is currently considered cryptographically secure — no practical collision attack has been demonstrated against it. It's the algorithm behind Bitcoin's proof-of-work system, most modern TLS certificate signatures, and the majority of software integrity checks published today.
Common real-world use cases:
- Verifying downloaded software (Linux ISOs, Docker images, GitHub release binaries) hasn't been tampered with
- Blockchain and cryptocurrency proof-of-work systems
- API request signing (AWS Signature Version 4, for example, uses HMAC-SHA256)
- File integrity monitoring in security tooling
- Digital certificates and code signing
One important nuance: SHA256 is a general-purpose hash function, not a password-hashing algorithm. Because it's designed to be fast, that speed actually becomes a weakness for password storage — a fast hash is easier to brute-force at scale. For passwords, use algorithms specifically designed to be slow and resource-intensive, like bcrypt, scrypt, or Argon2, not a raw SHA256 hash.
Try it yourself with the SHA256 Hash Generator — paste in any text or file content and see the output instantly.
Bonus: What About SHA512?
If SHA256 is the current standard, SHA512 is its bigger sibling — same SHA-2 family, but producing a 512-bit hash (128 hex characters) instead of 256-bit. It offers a larger security margin and, on 64-bit systems, can actually run faster than SHA256 due to how its internal operations are optimized. It's commonly used in certificate chains, cryptographic libraries, and systems that want extra headroom against future attacks. You can generate one with the SHA512 Hash Generator if your project calls for the added bit length.
Side-by-Side Comparison: MD5 vs SHA1 vs SHA256
| Feature | MD5 | SHA1 | SHA256 |
|---|---|---|---|
| Output size | 128-bit | 160-bit | 256-bit |
| Hash length (hex) | 32 characters | 40 characters | 64 characters |
| Speed | Very fast | Fast | Fast (slightly slower than MD5/SHA1) |
| Collision resistance | Broken (since 2004) | Broken (since 2017) | No known practical attack |
| Safe for security use? | No | No | Yes |
| Safe for password storage? | No | No | No — use bcrypt/Argon2 instead |
| Still acceptable for | Non-security checksums, cache keys | Git internals, legacy systems | Digital signatures, integrity checks, certificates |
| Recommended for new projects | No | No | Yes |
Quick Decision Guide: Which One Should You Actually Use?
Use MD5 if: you just need a fast, non-security identifier — detecting accidental file corruption, generating a cache key, or de-duplicating uploads where nobody is trying to trick your system.
Use SHA1 if: you're working with an existing system that already depends on it, like Git — but avoid it in any new security-relevant design.
Use SHA256 if: you're verifying file integrity for security purposes, signing data, building anything blockchain-related, or need a hash that will hold up against a determined attacker. When in doubt, SHA256 is the safe default in 2026.
Never use a raw hash — MD5, SHA1, or SHA256 — for passwords. Use a purpose-built password hashing algorithm like bcrypt or Argon2, which are intentionally slow to resist brute-force attacks. If you're building a login system, it's also worth reading up on passkeys vs. passwords as a modern alternative to password-based auth entirely.
Hashing vs. Encoding: A Common Mix-Up
A lot of developers confuse hashing with encoding, especially when Base64 enters the picture. They're fundamentally different: encoding (like Base64) is reversible and designed for safely transporting data, while hashing is one-way and designed for verification. If you've ever wondered why a Base64 string "looks encrypted" but isn't secure, our breakdown on Base64 vs. Encryption covers that distinction in detail — it pairs well with this guide since the two concepts get mixed up constantly.
Hashing vs. Unique Identifiers (UUIDs)
Another common point of confusion: hashes and UUIDs both look like random strings, but they solve different problems. A hash is derived from input data (the same input always gives the same hash), while a UUID is generated independently of any input, purely to be a unique identifier with an astronomically low chance of collision. If you're deciding between hashing a value versus generating a fresh unique ID for a database record or session token, our guide on UUID generation (v1, v4, v5) explains when each approach fits — and you can generate one instantly with the UUID Generator.
Try It Yourself
Reading about hash algorithms is one thing — seeing them work on real data makes the difference click immediately. Paste the same text into each tool below and compare the output length and format side by side:
If your workflow involves preparing data before hashing — like encoding URL parameters safely or validating a JSON payload — the URL Encoder/Decoder and JSON Formatter are useful companions for cleaning up data before you generate a hash from it. And if this whole conversation has you rethinking how your app handles passwords, the Password Generator and our guide on why strong passwords matter more than ever are worth a look next.
Frequently Asked Questions
Is SHA256 unbreakable? No cryptographic algorithm is theoretically "unbreakable," but SHA256 has no known practical collision attack as of 2026, and breaking it would require computational resources far beyond what's currently feasible.
Can I convert a hash back to the original text? No — hashing is one-way by design. What you might be thinking of are online "hash lookup" tools, which check a hash against a huge precomputed database of common passwords or strings (a rainbow table). That only works against weak or common inputs, not genuinely random or complex ones.
Why does Git still use SHA1 if it's broken? Git's use of SHA1 is primarily for object identification rather than cryptographic security in the traditional sense, and the SHAttered attack required deliberately engineered PDF-like structures. That said, the Git project has been rolling out SHA256 support for repositories that want stronger guarantees.
Which one should I use just to check if two files are identical? For simple duplicate detection where no one is trying to fool your system, MD5 or SHA1 are fine and fast. If the files come from an untrusted source or security matters at all, use SHA256.
Is SHA256 the same as encryption? No. Hashing is one-way and can't be reversed, while encryption is two-way and designed to be decrypted with the right key. If you want the full breakdown of that distinction, see Base64 vs. Encryption.
Related tools: MD5 Hash Generator · SHA1 Hash Generator · SHA256 Hash Generator · SHA512 Hash Generator · Password Generator · UUID Generator
