Passwords & Hashing
SHA-256 vs MD5 vs Bcrypt
A practical chooser for checksums, integrity fingerprints, and password storage so you pick the right hash workflow the first time.
In brief
What it is: SHA-256, MD5, and bcrypt are not competing defaults; they serve different jobs and carry different security expectations.
Why it matters: Knowing where each one fits helps people choose the right tool and defend that choice clearly.
Worth knowing: Use a password hash for credentials, SHA-256 for modern checksums, and MD5 only where a legacy compatibility check specifically requires it.
MD5, SHA-256, and bcrypt all produce fixed outputs from input data, but they are built for different jobs. Matching the algorithm to the task supports reliable checksums, password storage, and comparisons.
Use Argon2id for new password-storage designs, bcrypt for systems that already use it, SHA-256 for integrity fingerprints, and MD5 only for required legacy checksums.
Use Hash Identifier to check a stored value for a recognizable prefix. Several algorithms produce the same number of bytes, so a plain hex or Base64 value may need a check against the application that created it.
What actually separates them
- If a human password is involved in a new design, start with Argon2id. Use bcrypt when you are maintaining or migrating an existing bcrypt system.
- If you need a general-purpose content fingerprint, start with SHA-256.
- If an old system explicitly expects MD5, use it for compatibility and label that decision clearly.
- Use encryption when the receiver needs to recover the original content later.
| Hash | Best fit | Reversible | Fast or slow | Best matching tools |
|---|---|---|---|---|
| Bcrypt | Existing bcrypt password-storage and verification systems | No | Intentionally slow | Bcrypt Generator, Verify Bcrypt |
| SHA-256 | Integrity checks, fingerprints, deterministic comparisons | No | Fast | SHA-256 Generator |
| MD5 | Legacy checksum compatibility where collision resistance is not the goal | No | Fast | MD5 Generator |
Mistakes that lead to the wrong choice
- Using MD5 for new password storage.
- Using SHA-256 directly for passwords instead of a password-hashing function such as Argon2id.
- Treating bcrypt as a general-purpose checksum for files or payloads.
- Calling a hash “encrypted” in user-facing docs.
Decision questions
Should a new application choose bcrypt?
Prefer Argon2id for a new password-storage design. Bcrypt remains useful when an application already stores bcrypt hashes or Argon2id is unavailable.
Is SHA-256 obsolete because bcrypt exists?
They solve different problems. SHA-256 remains useful for deterministic integrity fingerprints.
When is MD5 acceptable?
Mainly when compatibility with a legacy process is the real requirement and you are clear that it is not for modern password storage.
Reproduce it with exact bytes
- Freeze the exact input bytes, including encoding and newline handling.
- Generate or verify the digest with a small known sample.
- Record the algorithm, comparison rule, and storage format where future maintainers can find it.
1. exact input bytes
2. hash or HMAC operation
3. constant-format comparison
4. document algorithm and encoding
