Hash functions are everywhere in software: passwords, file integrity checks, digital signatures, caches, and data structures. Most developers use them without fully understanding what's happening under the hood. This article explains the key hash algorithms, what makes them different, and when to use each one.
What a hash function does
A hash function takes an input of any size and returns a fixed-length output — the hash or digest. The same input always produces the same output. A different input (even one character different) produces a completely different output.
Hash functions have three properties that matter in practice:
- Deterministic — same input always gives the same hash
- One-way — you can't reverse the hash to recover the input (for cryptographic functions)
- Avalanche effect — a tiny change in input causes a completely different output
Hashing is not encryption. Encryption is reversible with a key. Hashing is designed to be irreversible.
MD5 — fast, broken, still everywhere
MD5 (Message Digest 5) produces a 128-bit (32-character hex) hash. It was designed in 1991 by Ron Rivest and was the dominant hash algorithm for a decade.
Why MD5 is broken for security:
MD5 has known collision vulnerabilities. A collision is when two different inputs produce the same hash. In 2004, researchers demonstrated practical MD5 collisions. By 2008, security certificates were forged using MD5 collisions. MD5 is now completely unsuitable for any security-sensitive use.
Where MD5 is still legitimate:
- Checksum verification for non-security purposes (e.g. confirming a download isn't corrupted, where a man-in-the-middle attack isn't a concern)
- Cache keys and ETags where collision resistance doesn't matter
- Legacy systems you cannot change
- Quick data fingerprinting in internal tooling
MD5 generates hashes in microseconds, which makes it useful when speed matters more than security.
SHA-1 — better than MD5, also broken
SHA-1 (Secure Hash Algorithm 1) produces a 160-bit (40-character hex) hash. It was designed by the NSA and published in 1995.
SHA-1 remained the standard for longer than MD5 because its collision vulnerabilities took longer to exploit practically. Google's Project Zero demonstrated a practical SHA-1 collision in 2017 (the "SHAttered" attack), requiring roughly 6,500 CPU-years of computation. Since then, major browsers, Git (partially), and certificate authorities have deprecated or removed SHA-1 support.
Do not use SHA-1 for:
- TLS/SSL certificates (already rejected by browsers)
- Digital signatures
- Password hashing
SHA-1 is still acceptable for:
- Non-security checksums where speed matters
- Legacy Git object hashes (Git is migrating to SHA-256 but slowly)
- Internal deduplication systems where the attacker controls neither input nor the system
SHA-256 — the current standard
SHA-256 is part of the SHA-2 family, designed by the NSA and published in 2001. It produces a 256-bit (64-character hex) hash.
No practical collision attacks exist against SHA-256. The best known theoretical attacks (meet-in-the-middle) still require computational work far beyond current technology. SHA-256 is what you should use for any new system that needs a general-purpose cryptographic hash.
SHA-256 is used for:
- File integrity verification (most Linux package managers, npm, pip)
- HTTPS certificates
- Bitcoin's proof-of-work and address generation
- HMAC (Hash-based Message Authentication Code)
- JWT signature verification (HS256 = HMAC-SHA256)
SHA-256 is slower than MD5 by roughly 2–3x but the difference only matters at very high throughput.
SHA-512 — when you want more margin
SHA-512 produces a 512-bit (128-character hex) hash. It's part of the same SHA-2 family as SHA-256. On 64-bit CPUs, SHA-512 is often faster than SHA-256 due to how the algorithm operates on 64-bit words internally.
SHA-512 provides a larger security margin but is otherwise equivalent to SHA-256 for most purposes. Use it when you want extra headroom against future attacks, especially for long-term archival integrity.
What about password hashing?
None of the above (MD5, SHA-1, SHA-256, SHA-512) should be used for hashing passwords. They are all too fast — an attacker with a GPU can test billions of hashes per second against a stolen database.
For passwords, use:
- bcrypt — 1999, deliberately slow, widely supported
- Argon2 — won the Password Hashing Competition (2015), memory-hard, the current best practice
- scrypt — memory-hard alternative to bcrypt
These are specifically designed to be slow and computationally expensive, which makes brute-force attacks impractical.
Quick reference
| Algorithm | Output length | Speed | Collision-resistant | Use for |
|-----------|--------------|-------|---------------------|---------|
| MD5 | 128-bit / 32 hex chars | Fastest | No | Non-security checksums, cache keys |
| SHA-1 | 160-bit / 40 hex chars | Fast | No | Legacy only |
| SHA-256 | 256-bit / 64 hex chars | Moderate | Yes | General purpose, TLS, file integrity |
| SHA-512 | 512-bit / 128 hex chars | Fast (64-bit) | Yes | Extra security margin |
| bcrypt/Argon2 | Variable | Slow by design | N/A | Password storage |
Generating hashes
To quickly generate and compare MD5, SHA-1, SHA-256, and SHA-512 hashes for any text, you can use SnappyTools Hash Generator — runs entirely in your browser, nothing is sent to a server.
The practical rule
- New system, security matters: SHA-256 or SHA-256/512
- Passwords: Argon2id or bcrypt (never a raw hash)
- Non-security checksums: MD5 is fine
- Legacy code you can't change: document the known limitations
- TLS, certificates, signatures: SHA-256 minimum, SHA-1 and MD5 are rejected by modern systems
Originally published at https://snappytools.app/hash-generator/