Passwords & Hashing · Field note
SHA-256 vs MD5 vs Bcrypt: When to Use Each One
A practical chooser for checksums, integrity fingerprints, and password storage so you pick the right hash workflow the first time.
Before you start
Keep the exact input bytes stable while you test. One changed newline, encoding step, or parser pass can change a hash or signature.
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.
Watch for: Using a general-purpose hash where a password hash is required or using a legacy checksum where modern integrity expectations apply.
Not all hashes solve the same problem. MD5, SHA-256, and bcrypt all produce fixed outputs from input data, but they are built for different jobs. Treating them as interchangeable is how teams end up with weak password storage, misleading checksums, or broken comparisons.
The easiest way to think about them is by use case: Argon2id for new password-storage designs, bcrypt for systems that already use bcrypt, SHA-256 for general integrity fingerprints, and MD5 only when an existing non-security checksum process requires it.
When you inherit a stored value instead of choosing the algorithm yourself, use Hash Identifier to inspect explicit format markers. Treat a bare hex or Base64 length as a set of possibilities, not authoritative proof of MD5, SHA-256, or another algorithm.
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.
- Do not use any of these hashes when the receiver must recover the original content later. That is an encryption task.
| 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?
No. 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