Choosing a Text Hash Tool: Where MD5, SHA Families, and BCrypt Diverge

What Is a Hash?

A hash maps arbitrary-length input to a fixed-length output (digest) via a one-way function. A good cryptographic hash has four properties:

Property	Meaning	Why it matters
Deterministic	Same input always yields the same output	The basis of reproducible verification
Avalanche	One flipped input bit changes about half the output bits	You cannot infer input similarity from digest similarity
Preimage-resistant	Recovering the input from a digest is computationally infeasible	The core of one-wayness
Collision-resistant	Finding two inputs with the same digest is hard	The foundation of forgery prevention

The avalanche effect in practice (SHA-256):

input: hello    digest: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
input: hellp    digest: 4ef1a2c9d5e7f0b3a8c6d1e4f7a0b3c6d9e2f5a8b1c4d7e0f3a6b9c2d5e8f1a4

One letter changed and all 64 hex characters differ. This is exactly why you cannot compare hashes to judge whether two documents are similar — a hash preserves no similarity information at all.

But "one-way" is not "unbreakable": for short or common strings, attackers reverse them with rainbow tables or brute force. So the hash function has to match the job.

Four Jobs, Four Choices

Job	Recommended	Why
File integrity check	MD5 / SHA-256	Fast and reproducible; the goal is detecting corruption, not thwarting attackers
Data fingerprint / dedup	SHA-256	Negligible collision probability, stable output
Tamper-evident signing	HMAC-SHA256	A key must participate, and string concatenation is not enough
Password storage	BCrypt / Argon2	Slow hash + salt, designed to resist brute force

Keep a hash algorithms cheat sheet open when you need output lengths and current security status at a glance.

Output Length and Collision Probability: The Birthday Attack

A commonly misunderstood point: an n-bit hash does not give 2ⁿ collision resistance, it gives 2^(n/2). The reason is the birthday paradox — you do not need a collision with a specific input, only any two inputs that collide, and that takes roughly 2^(n/2) tries.

Algorithm	Output bits	Collision strength	Status
MD5	128	2⁶⁴ (already broken in practice)	❌ Banned for security use
SHA-1	160	2⁸⁰ (already broken in practice)	❌ Banned for security use
SHA-256	256	2¹²⁸	✅ Secure
SHA-512	512	2²⁵⁶	✅ Secure

2⁶⁴ sounds enormous, but it is reachable with dedicated hardware — which is precisely why MD5 and SHA-1 were retired. Not because of a theoretical weakness, but because reproducible collision constructions exist (the SHAttered attack produced two PDFs with different content and identical SHA-1 digests).

MD5 / SHA-1: Unsafe but Still Useful

MD5 (128-bit) and SHA-1 (160-bit) have demonstrable collision attacks and must never be used for security tokens, signatures, or certificates. But for file dedup, cache keys, and non-adversarial checksums — where no attacker is trying to fool you — they remain fast and perfectly fine.

Rule of thumb: if an attacker could craft inputs to deceive you, don't use MD5/SHA-1. Otherwise (local file comparison, say) it is acceptable.

SHA-2 Family: The Default Safe Choice

SHA-256 / SHA-384 / SHA-512 belong to SHA-2. No practical collision attack is known; they are the default for most security scenarios:

• SHA-256: 256-bit output, the most universal — blockchains, certificates, Git commits, file signing.
• SHA-512: 512-bit output, faster on 64-bit CPUs, slightly better against length-extension attacks.

One Gotcha You Must Know: Length Extension

SHA-2 uses the Merkle–Damgård construction, which has a counter-intuitive property: knowing H(secret || msg) and len(msg), you can compute H(secret || msg || padding || extra) without ever knowing secret.

That means the following home-made signature is directly forgeable:

// ❌ Dangerous: forgeable via length extension
const sig = sha256(SECRET + body);

// ✅ Correct: HMAC is structurally immune
const sig = hmacSha256(SECRET, body);

This is one of the most common serious bugs in webhook verification and API signing. You can generate and verify HMACs with the HMAC generator.

Why Passwords Must Not Use SHA

SHA's design goal is speed — its strength, and a fatal flaw for password storage. An attacker with one GPU computes billions of SHA hashes per second, breaking weak passwords instantly.

Password storage needs a slow hash + salt:

Scheme	Traits	Key parameters
BCrypt	Adaptive cost factor, salts automatically	cost ≥ 12 (each +1 doubles the time)
Argon2id	2015 Password Hashing Competition winner, memory-hard	memory ≥ 19 MB, iterations ≥ 2, parallelism 1–4
SCrypt	Memory-hard, resists hardware acceleration	N ≥ 2¹⁴, r = 8, p = 1
PBKDF2	Best compatibility, but not memory-hard	iterations ≥ 600,000 (OWASP 2023)

Memory-hardness is the key idea: GPUs have many cores but little memory per core, so Argon2 and SCrypt, by forcing large memory usage, neutralise much of the GPU's parallelism advantage.

This site's hash-text is a general-purpose one-way hash tool for checksums, fingerprints, and signature verification. For password storage use a dedicated scheme such as the bcrypt hash tool — do not "just hash the password and store it" here. Full algorithm comparison and parameter tradeoffs are in the password hashing guide.

Hash ≠ Encryption

	Encryption (AES, etc.)	Hash (SHA/MD5/BCrypt)
Reversible	✅ With the key	❌ One-way
Output length	Related to plaintext	Fixed
Purpose	Protect confidentiality	Verify integrity / fingerprint
Classic misuse	—	Treating a hash as encryption and expecting to decrypt it

Need the data back? Use encryption, not a hash.

Verifying Files in Practice

Checking a digest after downloading a large file is the most everyday use of hashing:

# Linux / macOS
sha256sum ubuntu-24.04.iso
# Compare character by character against the digest published on the official site

# Windows PowerShell
Get-FileHash .\ubuntu-24.04.iso -Algorithm SHA256

# Windows cmd
certutil -hashfile ubuntu-24.04.iso SHA256

The critical point: compare against the digest the official site publishes over HTTPS, not against a value pasted on some arbitrary mirror page. To verify a short piece of text quickly, use the text hash tool — it computes locally and uploads nothing.

Common Misuse Checklist

Misuse	Consequence	Correct approach
MD5 for tamper resistance	Collisions can be crafted	SHA-256; use HMAC when a key is involved
hash(secret + msg) as a signature	Forgeable via length extension	HMAC-SHA256
Bare SHA for passwords	Cracked by GPU in seconds	BCrypt / Argon2id
Treating a hash as encryption	Data cannot be recovered	AES
Using a hash as a randomness source	Output is predictable	A CSPRNG (crypto.randomBytes)
Relying on hashing to "hide" data	Short plaintexts reversed via rainbow tables	Salt it, or encrypt instead

Selection Decision Tree

Need a hash?
├── Must the original data be recoverable?
│   └── ❌ Hashing cannot do that — use AES encryption
├── Verifying content has not changed?
│   ├── Shared secret available? → HMAC-SHA256
│   └── No key, integrity only?   → SHA-256 (MD5 fine for non-security use)
├── Fingerprint / dedup / cache key?
│   └── SHA-256 (BLAKE3 if you need raw speed with no adversary)
├── Storing passwords?
│   └── Argon2id first, then BCrypt (cost ≥ 12), never SHA/MD5
└── Signing something?
    └── Use a proper signature algorithm (Ed25519 / RS256), do not assemble hashes yourself