MD5 vs SHA-256 - when to use each hash function
MD5 and SHA-256 produce fixed-length fingerprints of arbitrary input data. They look interchangeable from the outside - paste text, get hex - but they solve different problems. MD5 is a fast, cryptographically broken fingerprint suitable for non-adversarial integrity checks. SHA-256 is a modern, cryptographically sound hash used anywhere an attacker might try to forge a collision. Picking the right one for the job saves CPU time and prevents real security gaps.
What a hash function actually does
A hash function takes input bytes of any length and returns a fixed-length digest. The same input always produces the same digest. Changing a single bit of input produces a completely different digest (the avalanche effect). The digest is one-way - you cannot reconstruct the input from the digest.
MD5 returns 128 bits (32 hex characters). SHA-256 returns 256 bits (64 hex characters). Both are deterministic. Both are fast. Both reveal nothing about the input structure from the output.
Side-by-side comparison
| Attribute | MD5 | SHA-256 |
|---|---|---|
| Digest length | 128 bits (32 hex chars) | 256 bits (64 hex chars) |
| Designed | 1991 (Ron Rivest) | 2001 (NSA, FIPS 180-2) |
| Family | MD4 lineage | SHA-2 family |
| Collision resistance | Broken since 2004 (Wang et al.); practical collisions in seconds | No known practical collision; ~2128 operations to find one |
| Second-preimage resistance | Weakened but no practical attack for pre-computed input | Strong; ~2256 operations |
| Speed (modern x86-64) | ~500 MB/s per core | ~300 MB/s per core (SHA-NI: ~1.5 GB/s) |
| Hardware acceleration | No dedicated instruction | Intel SHA-NI, ARMv8 crypto extensions |
| Safe for cryptographic use | No - do not use for signatures, cert pinning, password hashing | Yes (outside password hashing - use Argon2id/bcrypt for passwords) |
Why MD5 is broken and what that actually means
A collision is two different inputs that produce the same digest. MD5's collision resistance was theoretically broken in 2004 and practically broken by 2008 - a researcher can craft two files with identical MD5 digests in seconds on consumer hardware. This broke MD5's use in digital signatures (the Flame malware forged a Windows Update signature in 2012), TLS certificates (all major CAs stopped issuing MD5-signed certs by 2014), and any context where an adversary can influence the inputs.
MD5's second-preimage resistance is weaker than SHA-256's but has no known practical attack against arbitrary already-existing inputs. That's the narrow window where MD5 is still safe: confirming that an already-computed digest matches a file you downloaded, when no adversary had the chance to craft a collision against that specific file.
When MD5 is still fine
File integrity for non-adversarial environments. A Linux ISO download publishes an MD5 alongside the image; if the hash matches, your download wasn't corrupted in transit. There's no adversary crafting a forged ISO against that specific MD5 - they'd need to get their file published on the upstream site first.
De-duplication caches. A caching proxy keys objects by MD5 of their content to detect repeats. Collisions in this context are benign - two different objects with the same MD5 means one cache miss, no security consequence.
Database row fingerprinting. "Has this record changed since last sync?" - MD5 the row, compare to stored digest. Faster than SHA-256; the adversary model is absent.
Git content addressing. Git uses SHA-1 (soon SHA-256), not MD5 - but the design rationale applies: for a content-addressed store where you trust the writer, a 128-bit hash is sufficient if collision isn't an attack vector.
When SHA-256 is the correct choice
Digital signatures. TLS certificates, code signing, JWT signing - anywhere an attacker gains from forging a signature, use SHA-256 or stronger.
Cert pinning and public-key fingerprints. The SHA-256 fingerprint of a certificate's public key is the standard for pinning.
Blockchain and content-addressable storage where adversaries participate. Bitcoin uses SHA-256 twice (SHA-256d) for block headers and transaction identifiers. Any store where users contribute content and collisions could be exploited needs SHA-256.
HMAC for message authentication. HMAC-SHA-256 is the baseline for API request signing (AWS Signature v4, GitHub webhooks, Stripe). HMAC-MD5 is still used in some legacy protocols but is increasingly flagged by compliance scanners.
What to use for passwords (spoiler: neither)
Do not use MD5 or SHA-256 directly for password storage. Both are fast - that's bad for passwords. An attacker with a leaked digest can test billions of candidate passwords per second on a GPU. Use a password hashing function: Argon2id (OWASP 2025 recommendation), bcrypt, or scrypt. These functions are intentionally slow and memory-hard, so an attacker can test only thousands of candidates per second, not billions.
Performance reality in 2026
MD5 is still ~1.7× faster than SHA-256 on a CPU without SHA-NI. On CPUs with Intel SHA-NI (Goldmont+, 2017) or ARMv8 crypto extensions (Cortex-A53 onward), SHA-256 actually matches or exceeds MD5 throughput - the speed gap that motivated choosing MD5 in the 2000s no longer holds.
In-browser JavaScript with WebCrypto (crypto.subtle.digest('SHA-256', data)) reaches ~200 MB/s on a modern laptop. Our MD5 converter runs MD5 at similar speed via a wasm implementation.
The decision rule in one sentence
If an adversary can influence the inputs, use SHA-256 (or SHA-3, or BLAKE3). If you're fingerprinting your own data for caching, de-duplication, or change detection, MD5 is fine and slightly faster.
Related tools
- MD5 Converter - compute MD5 of text or a small file in-browser.
- Text Diff - compare two text blocks line-by-line.
- Text / HTML Editor - live-render HTML and Markdown.
- Current Time (ms) - epoch time for log correlation.
Why trust these tools
- Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
- Truly in-browser - no upload. Every file-processing tool on this site runs in your browser through modern Web APIs (File, FileReader, Canvas, Web Audio, WebGL, Web Workers). Your photo, PDF, audio, or text never leaves your device.
- No tracking during tool use. Analytics ends at the page view. The actual input you paste, drop, or capture is never sent to any server and never written to any log.
- Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
- Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.