MD5 should have been retired years ago. It still shows up in build scripts, legacy databases, and dedup caches across production systems in 2026, mostly because nobody wants to touch the code that generates it. SHA-256 replaced it as the default choice for anything security-sensitive over a decade ago, and it remains the backbone of TLS certificates, package integrity checks, and most of Bitcoin’s proof-of-work. What’s changed recently is less obvious: new benchmark data shows SHA-256 can now outrun MD5 on modern hardware, flipping a performance assumption that held for twenty years. This comparison walks through the real specs, the collision-attack history that broke MD5, current throughput numbers from three independent sources, and a practical migration path for anyone still carrying MD5 in production. See our cryptography hub for related deep dives into hash functions and signature schemes.

The stakes are higher than a routine spec-sheet comparison suggests, because a hash function sits underneath almost everything else in a security stack. Get the choice wrong on a certificate chain, an authentication token, or a file-integrity check, and every layer built on top of it inherits the weakness silently, often for years before anyone notices. That’s exactly what happened to the organizations still running MD5-signed certificates in the mid-2000s, and it’s the reason this comparison spends as much time on collision history and real incidents as it does on raw throughput numbers.

What MD5 and SHA-256 Actually Compute

Both algorithms are cryptographic hash functions built on the Merkle-Damgård construction: they chew input data in fixed-size blocks, update an internal state, and compress that state down to a fixed-length digest at the end. That’s where the similarity stops. MD5, designed by Ronald Rivest in 1991, processes 512-bit blocks through 64 rounds and outputs a 128-bit digest, usually shown as 32 hexadecimal characters. SHA-256, part of the SHA-2 family published by NIST in 2001, also processes 512-bit blocks but runs 64 rounds of a different, more complex compression function and produces a 256-bit digest, shown as 64 hex characters.

The digest length isn’t cosmetic. A 128-bit output gives MD5 a generic birthday-bound collision resistance of roughly 2^64 operations, a number GPUs cleared decades ago. SHA-256’s 256-bit output pushes that same generic bound to around 2^128, a search space still considered computationally out of reach with any known hardware, according to NIST’s Computer Security Resource Center.

Padding matters more than most developers realize. Both algorithms append a single “1” bit, a run of zero bits, and a 64-bit length field to the end of the message before splitting it into blocks, a technique known as Merkle-Damgård strengthening. That length field is what blocks trivial length-extension tricks against a raw, unpadded stream. It does not, on its own, stop the chosen-prefix collision technique that broke MD5, since that attack works by finding two different message blocks that push the internal state to the same value partway through, well before the final padding and length field ever come into play.

MD5 vs SHA-256: Full Specification Comparison

The table below lines up every spec that matters when deciding whether either algorithm belongs in a 2026 codebase.

SpecMD5SHA-256
Digest size128 bits (32 hex chars)256 bits (64 hex chars)
Internal block size512 bits512 bits
Compression rounds6464
DesignerRonald RivestNSA, published via NIST
Year published19912001
Governing standardRFC 1321 (informational, not FIPS-approved)FIPS 180-4 (NIST Secure Hash Standard)
Generic collision-resistance bound~2^64 operations~2^128 operations
Generic preimage-resistance bound~2^128 operations~2^256 operations
Known practical collision attackYes, chosen-prefix collisions since 2007None known as of September 2026
Hardware acceleration in siliconNone (no dedicated instruction set)Intel SHA-NI, ARMv8 Cryptography Extensions
FIPS-approved for security useNoYes
Typical software-only throughput (large blocks)~534 MB/s~88 MB/s
Typical hardware-accelerated throughput~0.5-0.7 GB/s~1.2-2.6 GB/s

Notice the last two rows contradict each other, and that’s not a typo. Software-only figures (no crypto extensions in play) favor MD5’s simpler math. Once hardware acceleration enters the picture, the ranking flips. The benchmarks section below breaks down exactly why.

The Collision Timeline: How MD5 Got Broken

MD5’s downfall didn’t happen overnight. Xiaoyun Wang and colleagues published the first practical collision attack in 2004, showing that two distinct messages could be crafted to produce the same MD5 digest. That result alone didn’t kill MD5 in the field, because a plain collision attack requires the attacker to control both colliding messages, which limits real-world damage.

Chosen-prefix collisions changed that calculus. Researcher Marc Stevens and collaborators demonstrated that an attacker could pick two arbitrary, meaningful prefixes, such as two different X.509 certificate identities, and then compute matching suffixes that force both documents to the same MD5 hash. Their published cryptanalysis estimated the attack at roughly 2^39 calls to the MD5 compression function, translating to about a day of compute on a standard quad-core PC at the time of publication. On modern GPU clusters that cost has only dropped further, though no independently audited 2025-2026 benchmark figure for the exact dollar cost currently exists in public research.

The most consequential demonstration came in 2008, when a research team built a rogue certificate authority certificate by exploiting an MD5 chosen-prefix collision inside a real CA’s signing chain. That proof of concept is the reason every publicly trusted certificate authority moved off MD5-signed certificates within a few years, well before regulators forced the issue.

The Flame Malware Incident: MD5’s Most Damaging Real-World Exploit

The clearest evidence that MD5’s weakness moved from academic curiosity to active battlefield tool arrived in 2012, when researchers discovered the Flame espionage malware spreading across systems in the Middle East. Microsoft’s own security response team confirmed what made Flame different from ordinary malware: its authors forged a valid Microsoft digital certificate by exploiting a previously unknown variation of a chosen-prefix collision attack against MD5.

The attackers targeted Microsoft’s Terminal Services licensing certificate chain, which still relied on an MD5-based signature and, critically, chained up to a trusted Microsoft root authority. By computing a collision, they produced a certificate that Windows treated as a legitimate Microsoft code-signing certificate. That let Flame impersonate Windows Update on a compromised network and push its own malicious components to other machines as if they were signed, trusted patches. Researcher Alex Sotirov’s published technical analysis of the collision confirmed it used a novel attack method not previously documented in academic literature, meaning Flame’s authors had cryptanalysis capability ahead of the public research at the time.

Microsoft responded by revoking the affected certificates and issuing Security Advisory 2718704, and the incident became the strongest real-world argument security teams had for finally killing MD5 in anything touching code signing or certificate chains. It’s also a useful reminder that theoretical cryptanalysis rarely stays theoretical for long once nation-state-level resources decide it’s worth the investment.

Is SHA-256 Still Secure in 2026?

Yes, and NIST’s own guidance backs that up. SHA-256 remains listed under FIPS 180-4 with a stated 128-bit collision-resistance strength and 256-bit preimage-resistance strength. No published cryptanalysis has found a practical collision or preimage attack against full SHA-256. The closest thing to a scare in the SHA family hit SHA-1, not SHA-2, and that’s precisely why browsers and certificate authorities pushed the entire industry to SHA-256 in the first place.

NIST didn’t stop at SHA-2. The agency finalized SHA-3 as a structurally different backup standard, built on the Keccak sponge construction rather than Merkle-Damgård, specifically so the ecosystem wouldn’t be caught flat-footed if a future attack targeted the Merkle-Damgård design pattern that both MD5 and SHA-256 share. That’s a hedge against a hypothetical, not a response to any confirmed SHA-256 weakness. For a deeper look at how the two compare on real workloads, see our SHA-256 vs SHA-3 benchmark comparison. SHA-256’s larger sibling gets its own detailed rundown in SHA-256 vs SHA-512.

Bitcoin’s mining network is, in effect, the largest ongoing stress test SHA-256 has ever faced, hashing at exahash scale around the clock since 2009. That workload has never produced a collision or forced a protocol change to the hash function itself, which is as close to a real-world endurance test as a cryptographic primitive gets.

SHA-256 in Bitcoin: A Global-Scale Stress Test

Bitcoin’s proof-of-work system applies SHA-256 twice to every candidate block header, a design choice Satoshi Nakamoto made in the original 2008 whitepaper specifically to guard against a class of length-extension attacks. Miners worldwide compute that double SHA-256 operation continuously, competing to find a header whose hash falls below a network-wide difficulty target. The scale of that effort is hard to overstate: the combined hash rate of the Bitcoin network represents more sustained SHA-256 computation than any other single application on the planet.

What makes this relevant to a security comparison, rather than just a crypto trivia point, is that Bitcoin’s mining network functions as an unintentional, continuously running cryptanalysis bug bounty. Every miner has a direct financial incentive to find any shortcut, weakness, or faster path through SHA-256 that would let them out-compute every other participant. None has surfaced in over fifteen years of that adversarial pressure, which is a meaningfully different kind of validation than a lab paper concluding no attack is currently known.

Benchmark Data: MD5 vs SHA-256 Throughput on Current Hardware

Three independent benchmark sources tell a more nuanced story than “MD5 is faster.” The table below separates software-only results from hardware-accelerated results, because conflating the two is where most outdated comparisons go wrong.

SourceTest environmentMD5 throughputSHA-256 throughput
OpenSSL speed benchmark (community-run, 8192-byte blocks)x86 software path, no crypto extensions~534 MB/s~88 MB/s
Daniel Lemire, January 2025Apple M2, Bun 1.31 / Node.js 23, 1 GB random data0.6-0.7 GB/s2.6 GB/s
Daniel Lemire, January 2025Intel Ice Lake server, same runtime~0.7 GB/s~1.2 GB/s
Daniel Lemire, January 2025AWS Graviton4 (ARMv8), same runtime0.5-0.6 GB/s~1.8 GB/s

The gap between rows one and two is the entire story. Without hardware acceleration, MD5’s simpler bitwise operations let it move roughly six times faster than SHA-256 in raw software. Turn on crypto extensions, which ship in effectively every x86-64 chip since around 2013 and every recent ARMv8 server or mobile core, and SHA-256 pulls ahead by a factor of two to four depending on the platform. Lemire’s own conclusion, published on his blog after running the numbers: “My results suggest that you should probably not be using MD5. MD5 is slower than SHA-256 and not as safe.” That’s a direct, sourced reversal of two decades of conventional wisdom about hash function speed.

These single-thread figures also understate what either algorithm can do in a real pipeline. Hashing independent files or independent chunks of a large object parallelizes almost perfectly across CPU cores, since each hash computation has no dependency on any other. A build system or backup tool checksumming a directory of files with eight worker threads gets roughly eight times the single-thread throughput shown above, whichever algorithm it’s running. That scaling factor applies equally to both algorithms, so it doesn’t change the relative comparison between them, but it does mean the absolute wall-clock time for hashing a large dataset in production is usually far lower than the single-core numbers in the table would suggest.

Why SHA-256 Can Now Outrun MD5

The mechanism behind that reversal is straightforward once you look at what chipmakers actually built. Intel introduced SHA Extensions (SHA-NI) starting with Goldmont-class cores and mainstream desktop chips a few years later, giving SHA-256 a dedicated instruction path that computes several rounds of the compression function per cycle. ARM did the same with the Cryptography Extensions built into ARMv8, which now cover everything from Apple Silicon to AWS Graviton server chips.

MD5 never got that treatment, and it never will. Chipmakers don’t burn silicon accelerating an algorithm that NIST and every major security body have told developers to stop using for two decades. So MD5 is permanently stuck running through generic integer and logic instructions, while SHA-256 gets a purpose-built fast path on nearly every processor shipped since the early 2010s. The algorithm with the objectively weaker security margin also lost the hardware arms race, which is a rare case of the more secure choice becoming the faster choice too.

If raw throughput is the priority and MD5-level security is fine, newer general-purpose hash functions like BLAKE3 outperform both by a wide margin on modern CPUs. Our BLAKE3 vs SHA-256 breakdown has the numbers.

Why MD5’s Speed Makes It Dangerous for Passwords

The same property that makes MD5 attractive for checksums, raw speed, is exactly what makes it a liability the moment it touches a password field. Password-cracking tools are built to exploit fast hash functions at massive scale, and GPUs are purpose-built for the kind of parallel, repetitive math both MD5 and SHA-256 require. Community-reported hashcat benchmarks compiled by Online Hash Crack and independent GPU testers show a single Nvidia RTX 5090 pushing well over 240 GH/s against raw MD5, meaning a modern flagship consumer GPU can attempt hundreds of billions of password guesses every second against an unsalted MD5 hash.

SHA-256 doesn’t fix that problem on its own. It’s slower per hash than MD5 in a GPU cracking context too, since both were designed for throughput rather than resistance to brute force, and a determined attacker with cloud GPU rentals will still cycle through billions of raw SHA-256 guesses per second. That’s precisely why the use-case table below draws such a hard line: password storage needs Argon2id, scrypt, or bcrypt, algorithms deliberately built to be slow and memory-hard so that the same GPU horsepower that cracks MD5 in minutes takes years against a properly configured KDF.

MD5 and SHA-256 on the Command Line

Every major operating system ships both algorithms as built-in utilities, which is part of why MD5 has been so slow to disappear. Anyone auditing a codebase can check both digests for a file in seconds.

# Linux / most package managers
md5sum firmware.bin
sha256sum firmware.bin

# macOS
md5 firmware.bin
shasum -a 256 firmware.bin

# Cross-platform via OpenSSL
openssl dgst -md5 firmware.bin
openssl dgst -sha256 firmware.bin

The output length gives the algorithm away at a glance: a 32-character hex string is MD5, a 64-character hex string is SHA-256. That’s a useful sanity check when auditing a legacy system, since it’s common to find MD5-shaped columns and environment variables that nobody remembers adding.

What It Costs to Hash Data at Scale

Neither algorithm is a paid product, so there’s no license fee to compare. What actually costs money is the compute time to hash large datasets, and that cost tracks directly with the throughput numbers above. Using AWS EC2 on-demand pricing for a c7i.large instance, listed at roughly $0.0645 per hour in the us-east-1 region as of late 2026, here’s what it costs in raw compute to hash 100 TB of data end to end on a single instance.

ScenarioThroughputTime to hash 100 TBEst. compute cost
MD5, software-only (no crypto extensions)534 MB/s~52 hours~$3.35
SHA-256, software-only (no crypto extensions)88 MB/s~316 hours~$20.36
MD5, modern runtime, no hardware speedup available~650 MB/s~43 hours~$2.75
SHA-256, modern runtime with crypto extensions~2.6 GB/s~11 hours~$0.69

The single-instance, single-thread numbers above are illustrative, not a production sizing guide, since real pipelines parallelize across cores and instances. But the direction holds at any scale: on current-generation silicon, SHA-256 is now the cheaper option to run, not just the safer one. That’s a genuinely new argument for standardizing on SHA-256 even in the non-security corners of a codebase where MD5 has lingered purely out of habit.

Storage and Indexing Overhead: Does the Longer Digest Matter?

SHA-256’s 64-character hex digest takes exactly double the raw bytes of MD5’s 32-character output, 32 bytes versus 16 bytes in binary form. At small scale that difference is invisible. At the scale of a content-addressable storage system tracking billions of objects, it starts to show up in index size, cache-line efficiency, and replication bandwidth for the hash column itself.

In practice, most systems store hashes as binary rather than hex text, which halves the overhead immediately, and the extra 16 bytes per row rarely competes with the size of whatever the hash is actually protecting. A database storing SHA-256 digests for a billion rows spends roughly 16 GB more on that column than the equivalent MD5 column would, which is a rounding error next to the storage most systems dedicate to the underlying data, logs, and indexes around it. Sharding schemes that use a hash prefix as a partition key work identically either way, since both digests distribute uniformly across their output space. The storage argument for MD5 mattered more in the 1990s, when 16 bytes per row was a meaningfully larger fraction of total disk cost than it is today.

Where Each Algorithm Still Shows Up in 2026

Neither algorithm is going away entirely, even if only one of them belongs in new security-sensitive code. Here’s where each actually turns up in production systems right now.

  • TLS certificate signatures. RFC 9155 formally deprecated MD5 and SHA-1 signature hashes in TLS 1.2 and DTLS 1.2, and every publicly trusted certificate authority has required SHA-256 or stronger for certificate signing for well over a decade. See our TLS 1.3 vs TLS 1.2 adoption breakdown for how that plays out across the current protocol landscape.
  • Package registry integrity checks. npm’s lockfiles and pip’s hash-checking mode both record SHA-256 or SHA-512 digests to verify that a downloaded package matches what the publisher shipped.
  • Container image digests. Docker and OCI image manifests are addressed by their SHA-256 digest, which is exactly what lets `docker pull image@sha256:…` pin a build to one exact, immutable artifact.
  • Git’s in-progress hash transition. Git has shipped an experimental SHA-256 object format since version 2.29, released in 2020, and the project has targeted Git 3.0, expected in late 2026, to make SHA-256 the intended default going forward. GitHub still only supports SHA-1 repositories today, which remains the single biggest reason most real-world Git history is still on the older, weaker hash.
  • Cloud API request signing. AWS Signature Version 4, the scheme behind almost every authenticated AWS API call, runs on HMAC-SHA256. Our HMAC vs SHA-256 explainer covers how the keyed and unkeyed versions of the algorithm differ.
  • Non-security checksums. Backup tools, some deduplication caches, and internal cache-key generators still use MD5 purely to catch accidental corruption, not to resist a deliberate attacker. That’s a legitimate, low-risk use, provided nobody mistakes it for an authentication mechanism.

The pattern across all six examples is consistent: wherever an outside attacker could plausibly benefit from forging a match, the industry has already moved, or is actively moving, to SHA-256. Wherever the hash only needs to catch accidents or honest mistakes, MD5’s legacy footprint has been allowed to persist because ripping it out carries real engineering cost for very little marginal security benefit.

Migrating Legacy Systems From MD5 to SHA-256

Ripping MD5 out of a codebase that’s carried it for a decade rarely works as a single flag-day cutover. A staged migration keeps the system verifiable at every step and gives you a rollback path if something downstream assumed a 32-character hex string. Most teams that have gone through this treat it as a multi-sprint project rather than a single ticket, precisely because MD5 tends to be wired into more places than anyone remembers, from database triggers to third-party webhook signature checks. Compliance pressure has only increased the urgency: PCI DSS and SOC 2 auditors increasingly flag any live MD5 usage as a finding, even in non-security contexts, simply because distinguishing “safe” MD5 usage from “unsafe” MD5 usage requires manual review that most audits aren’t scoped to do.

  1. Inventory every place MD5 appears: application code, database columns, cron jobs, config files, and third-party integrations that expect an MD5-shaped value.
  2. Classify each use as security-relevant (authentication, signatures, verifying untrusted input) or non-security (cache keys, dedup fingerprints, accidental-corruption checks).
  3. Prioritize the security-relevant cases first, since those are the ones a chosen-prefix collision can actually exploit.
  4. Add a parallel SHA-256 field or column alongside the existing MD5 one instead of overwriting it immediately.
  5. Dual-write both digests for new records while backfilling SHA-256 for historical data in a background job.
  6. Update client libraries, SDKs, and any code that hard-codes hash length, since MD5 hex strings are 32 characters and SHA-256 hex strings are 64.
  7. Flip read paths over to verify against SHA-256 once backfill coverage is confirmed complete across the dataset.
  8. Remove the MD5 write path, and drop the MD5 column once retention and compliance requirements allow it.
  9. Re-run integrity and regression tests against both normal and adversarially crafted inputs to confirm the cutover didn’t silently break downstream consumers.

A minimal dual-write helper during the transition period looks like this:

import hashlib

def compute_digests(data: bytes) -> dict:
    return {
        "md5": hashlib.md5(data).hexdigest(),        # legacy field, dual-write only
        "sha256": hashlib.sha256(data).hexdigest(),  # new source of truth
    }

Keep the MD5 output around only as long as something downstream still reads it. Once every consumer verifies against SHA-256, the MD5 branch becomes dead weight and a compliance liability, since auditors increasingly flag its presence even in non-security contexts.

Stacking every advantage and drawback side by side makes the decision easier than the specs table alone can. The lists below separate what each algorithm genuinely gets right from what should disqualify it for new work.

MD5 Pros and Cons

MD5 advantages

  • Faster than SHA-256 in pure software, with no hardware crypto extensions available
  • Shorter 128-bit digest saves storage in high-volume, non-security dedup tables
  • Nearly universal library support across every language and platform, including decades-old systems
  • Still fine for catching accidental corruption where nobody is trying to forge a match

MD5 disadvantages

  • Broken against chosen-prefix collision attacks since 2007
  • Not FIPS-approved for cryptographic security use
  • Rejected outright by TLS 1.2/DTLS 1.2 per RFC 9155 and by every modern browser’s certificate validation
  • No hardware acceleration path exists or is coming, since chipmakers won’t invest silicon in a deprecated algorithm
  • On accelerated hardware, it’s now slower than the more secure alternative, eliminating its last practical advantage

SHA-256 Pros and Cons

SHA-256 advantages

  • No known practical collision or preimage attack as of September 2026
  • FIPS 180-4 approved and required across TLS, code signing, and most compliance frameworks
  • Hardware-accelerated on nearly all modern x86-64 and ARMv8 chips, closing or reversing the old speed gap with MD5
  • 128-bit generic collision-resistance margin, double MD5’s broken 64-bit bound
  • Battle-tested at exahash scale by Bitcoin’s mining network since 2009

SHA-256 disadvantages

  • Slower than MD5 on hardware without crypto extensions, including some older embedded and IoT chips
  • Larger 64-character digest means more storage and index overhead at very high volume
  • Like MD5, it’s fast by design, which makes it unsuitable for password hashing without a dedicated KDF wrapper

5 Use Cases and Which Algorithm Fits

Most of the confusion around MD5 and SHA-256 comes from treating them as interchangeable general-purpose tools rather than picking based on the actual threat model. The recommendations below map common engineering scenarios directly to the algorithm that fits, along with the reasoning that should drive the choice rather than habit or whatever the last engineer on the project happened to use.

  1. Verifying a downloaded ISO or installer. Use SHA-256 or stronger. Most vendors already publish SHA256SUMS files, and MD5 checksums for downloads offer no protection against a tampered mirror.
  2. Signing or validating TLS certificates. SHA-256 only. MD5 signatures are rejected outright by modern TLS stacks and browsers.
  3. Non-adversarial cache keys or dedup fingerprints. MD5 remains technically acceptable here since nobody is trying to forge a collision, though SHA-256 is now the safer default given how close the performance gap has become on modern hardware.
  4. Storing or verifying user passwords. Neither MD5 nor raw SHA-256. Use Argon2id, scrypt, or bcrypt with a unique per-user salt. Our PBKDF2 vs Argon2 cracking-cost comparison explains why fast general-purpose hashes fail at this job.
  5. Authenticating API requests or webhook payloads. HMAC-SHA256, not HMAC-MD5. The keyed construction matters as much as the underlying hash choice here.
  6. Content-addressable storage and build reproducibility. SHA-256, which is exactly what Docker image digests, most package managers, and Git’s future object format already use or are moving toward.

Common Myths About MD5 and SHA-256

“MD5 is fine if I just need a quick hash” undersells how easy it is for a quick hash to end up guarding something adversarial six months later, once a new feature reuses that same field for verification. The safer default is to just start with SHA-256 and skip the migration entirely.

“SHA-256 is quantum-proof” isn’t quite right either. Grover’s algorithm theoretically halves the effective security margin of symmetric primitives like hash functions against a sufficiently large quantum computer, which would take SHA-256’s 128-bit collision bound down to roughly 64-bit-equivalent effort. That’s a future risk under active NIST study, not a reason to worry about SHA-256 today, since no quantum computer anywhere near that scale exists yet.

“A longer digest always means a slower hash” is the myth this whole comparison exists to correct. SHA-256’s 256-bit output used to mean more compression rounds and more math per byte than MD5’s 128-bit output, and on unaccelerated hardware, it still does. But hardware acceleration doesn’t care about the theoretical operation count, it cares about what silicon vendors chose to build a fast path for, and they chose SHA-256.

“Nobody actually uses MD5 anymore” is the last myth worth killing. Legacy financial systems, older embedded firmware update tools, some backup and sync software, and plenty of internal enterprise scripts written a decade or more ago still call MD5 every day. The algorithm isn’t a museum piece, it’s a live dependency in production systems that nobody has scheduled time to fix, which is exactly the gap the migration guide above is meant to close.

The Verdict: MD5 vs SHA-256 in 2026

SHA-256 wins on every axis that matters for new development: a 128-bit collision margin that’s held for over two decades with no known practical break, mandatory status across TLS, code signing, and compliance frameworks, and, as of Daniel Lemire’s January 2025 benchmarks, better real-world throughput on any chip with SHA-NI or ARMv8 crypto extensions, which covers the overwhelming majority of hardware shipping in 2026. The compute-cost math backs that up directly: hashing 100 TB costs roughly $0.69 on accelerated SHA-256 versus $3.35 on software-only MD5, using current AWS on-demand pricing.

MD5 isn’t extinct, and it doesn’t need to be. Non-adversarial checksums, legacy cache keys, and systems where switching the hash length would break more than it fixes are all reasonable places to leave it alone for now. What MD5 should never touch again is anything an attacker could plausibly want to forge: certificates, signatures, authentication tokens, or file-integrity checks on untrusted downloads. For those, SHA-256 has been the right call for years, and now it’s also the faster one.

The practical takeaway for a team auditing its own stack: don’t treat this as an all-or-nothing rewrite. Pull the inventory list from the migration guide above, sort by which uses touch anything an outsider could tamper with, and fix those first. Everything else can wait for the next scheduled refactor, since the actual security exposure from a well-contained, non-adversarial MD5 checksum is close to zero. The goal is eliminating risk where it’s real, not chasing a clean grep result for its own sake.

Frequently Asked Questions

Is MD5 still safe to use in 2026?

Not for anything adversarial. Chosen-prefix collision attacks have been practical since 2007, and RFC 9155 formally deprecated MD5 signature hashes in TLS. It remains acceptable only for non-security uses like accidental-corruption checks, where nobody is trying to forge a matching hash on purpose.

Can SHA-256 be broken the same way MD5 was?

No known practical collision or preimage attack exists against SHA-256 as of September 2026. NIST’s FIPS 180-4 still lists it with a 128-bit generic collision-resistance bound, and it remains the standard for TLS, code signing, and most compliance frameworks.

Is SHA-256 really faster than MD5 now?

On hardware with crypto extensions, yes. Daniel Lemire’s January 2025 benchmarks measured SHA-256 at up to 2.6 GB/s on Apple M2 versus roughly 0.6-0.7 GB/s for MD5 on the same chip. Without hardware acceleration, MD5’s simpler math still runs faster in pure software.

Should I use MD5 or SHA-256 to hash passwords?

Neither. Both are designed to be fast, which is exactly the wrong property for password storage since it makes offline guessing cheap. Use a dedicated password hashing function like Argon2id, scrypt, or bcrypt with a unique per-user salt.

Why do some tools still use MD5 in 2026?

Mostly legacy inertia and non-security checksums. Ripping an embedded hash function out of a decade-old system touches every downstream consumer that assumes a 32-character hex string, which makes teams postpone the migration even when it’s clearly overdue.

What replaced MD5 in TLS?

SHA-256, formalized by RFC 9155, which deprecated MD5 and SHA-1 signature hashes in TLS 1.2 and DTLS 1.2. Every publicly trusted certificate authority has required SHA-256 or stronger signatures for well over a decade.

Will Git ever fully drop SHA-1 for SHA-256?

Git has supported an experimental SHA-256 object format since version 2.29, and the project has targeted Git 3.0, expected in late 2026, to make it the intended default. GitHub still doesn’t support SHA-256 repositories, which remains the biggest practical blocker to a full ecosystem transition.

Is SHA-3 a replacement for SHA-256?

No. NIST published SHA-3 as a structurally different backup standard built on the Keccak sponge construction, as a hedge against a hypothetical future weakness in the Merkle-Damgård design both MD5 and SHA-256 share, not because SHA-256 itself has been broken.

How fast can a GPU crack an MD5 hash?

Community-reported hashcat benchmarks put a single Nvidia RTX 5090 at over 240 GH/s against raw MD5, meaning hundreds of billions of guesses per second on one consumer GPU. That’s exactly why raw MD5, and raw SHA-256 for that matter, should never store a password directly.

Does switching from MD5 to SHA-256 break existing hashes?

Yes, the digests are structurally different and can’t be converted between formats. Every migration requires either recomputing SHA-256 from the original source data or running a dual-write period where both hashes exist side by side until every consumer has cut over.