SecurityHashingMD5SHA-256Developer Tools

MD5 vs SHA-256: Which Hash Should You Use (and When It Doesn't Matter)

•By Hamid Abderrahim

Every developer eventually meets a checksum box: "verify the SHA-256 sum of the downloaded ISO", "compare the MD5 of the backup", "publish the digest alongside the release". Hash functions are everywhere, and the choice between MD5 and SHA-256 is simultaneously simple and misunderstood. This guide explains what hash functions guarantee, where each one belongs, and how to verify any file in your browser with the File Hash Generator.

What a hash actually computes

A cryptographic hash takes input of any size — a password, a 5 GB video, a single byte — and produces a fixed-size fingerprint. SHA-256 always outputs 256 bits, conventionally shown as 64 hexadecimal characters. Change one byte anywhere in the input and the fingerprint changes completely; this is the avalanche effect.

The fingerprint is one-way. You cannot reconstruct a file from its hash, and finding two different inputs with the same hash (a collision) should be computationally infeasible — should be, because that is exactly where MD5 fails.

Where MD5 stands in 2026

MD5 produces a 128-bit hash and is cryptographically broken — researchers demonstrated practical collisions back in 2004, and attackers have used forged MD5 signatures in real incidents (the famous Flame malware forged a Microsoft code-signing certificate this way). For anything adversarial — signatures, certificates, password storage, integrity against tampering — MD5 is disqualified.

Yet MD5 has not disappeared, because one legitimate use remains: non-adversarial checksums. If your goal is detecting accidental corruption — a truncated transfer, a flaky disk block, a mis-synced backup — MD5 still works. Accidental corruption does not craft collisions. It is also still the de-facto standard in some legacy pipelines (older CMS checksums, some academic datasets, embedded tooling).

The rule of thumb:

  • Adversary may exist → SHA-256 or better, always.
  • Only accidents to guard against → MD5 is acceptable; SHA-256 costs little more, so prefer it anyway.

Why SHA-256 is the default

SHA-256 (from the SHA-2 family) has withstood more than two decades of cryptanalysis with no practical collision attack. It is the default in TLS certificates, Bitcoin, package managers, code-signing, and secure file distribution. If you are publishing a download and a checksum, publish SHA-256. If you are building any system where a mismatch must imply tampering — not just corruption — SHA-256 is the floor.

(SHA-3 and BLAKE3 exist as newer alternatives; SHA-256 remains the pragmatic, universally supported choice.)

The classic use case: verifying a download

You download a Linux ISO or a library release. The project publishes sha256sums.txt. The procedure:

  1. Download the file.
  2. Compute its SHA-256 hash locally.
  3. Compare with the published value, character by character.
  4. A full match means the file is bit-for-bit what the publisher shipped.

If the hashes differ, either the transfer corrupted the file or something between the publisher and your disk altered it. Either way: re-download, then investigate.

Doing this in the browser is particularly convenient because the file never leaves your machine — the hashing runs in your browser via the Web Crypto API. The File Hash Generator computes MD5, SHA-1, SHA-256 and SHA-512 locally, with no upload. Because browsers only implement SHA natively, a correct MD5 implementation has to be built from scratch — a good sign that the tool's authors care about correctness (it should pass the official RFC 1321 test vectors).

Hashes are also privacy tools

Two files with identical SHA-256 hashes are provably identical. That property has everyday uses:

  • Deduplication — find duplicate photos or documents in a folder without opening any of them.
  • Chain of custody — record a file's hash before sending it; the recipient can later confirm nothing changed.
  • Tamper evidence — publish a hash now, and anyone can later verify the file has not been touched since.

One caution: hashing a short, guessable input (like a password) does not protect it — attackers hash candidate passwords at billions per second. Password storage needs slow, salted algorithms (bcrypt, Argon2), not bare SHA-256. For generating strong passwords to begin with, use the Password Generator.

Frequently asked questions

Is MD5 safe to use at all?

Only for detecting accidental corruption among trusted parties. Never for signatures, certificates, password storage, or anything an attacker could influence.

Can two different files have the same SHA-256?

Mathematically possible, practically no — the 2^256 space makes finding a collision infeasible with any foreseeable computing power.

Why is my hash different from a friend's hash of the same file?

You are hashing different bytes. Different download versions, modified metadata, or line-ending conversion (CRLF vs LF) all change the input — and therefore the entire fingerprint.

How do I verify a download without installing anything?

Open the File Hash Generator, drop the file in, and compare the SHA-256 output with the publisher's value — everything happens in your browser.

Verify your next download: drop any file into File Hash Generator for instant MD5/SHA-1/SHA-256/SHA-512 digests, and double-check text changes with Text Diff — both fully client-side.