Initializing, please wait a moment

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

AttributeMD5SHA-256
Digest length128 bits (32 hex chars)256 bits (64 hex chars)
Designed1991 (Ron Rivest)2001 (NSA, FIPS 180-2)
FamilyMD4 lineageSHA-2 family
Collision resistanceBroken since 2004 (Wang et al.); practical collisions in secondsNo known practical collision; ~2128 operations to find one
Second-preimage resistanceWeakened but no practical attack for pre-computed inputStrong; ~2256 operations
Speed (modern x86-64)~500 MB/s per core~300 MB/s per core (SHA-NI: ~1.5 GB/s)
Hardware accelerationNo dedicated instructionIntel SHA-NI, ARMv8 crypto extensions
Safe for cryptographic useNo - do not use for signatures, cert pinning, password hashingYes (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.


MD5 or SHA-256: the trust-boundary rule

The choice between MD5 and SHA-256 turns on a single question - whether an adversary can influence the input you are hashing. If a remote uploader, a network attacker, or any party outside your trust boundary can shape the bytes that reach the hash function, pick SHA-256 (or SHA-3, or BLAKE3) so that a collision attack cannot forge a matching digest. If the inputs come from your own pipeline and you are fingerprinting them for caching, de-duplication, or change detection, MD5 is fine and runs slightly faster on CPUs without SHA-NI acceleration. The decision is binary and it lives at the trust boundary; once you have named which side of that boundary the input sits on, the algorithm to use is determined.


Related tools


← Back to Developer Tools

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.
  • No install, no sign-up. Open a tool and get a working output in seconds - nothing to download and no account to create. Tools that need heavy processing run it on our service, so even a low-powered machine gets the job done.
  • Analytics stops at the page view. We measure which pages get visited, not what you type or upload inside a tool. There is nothing to sign in to and no profile is attached to your input.
  • 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.