Hashing explained: MD5, SHA-1 and SHA-256, checksums, and why a hash is not encryption

A hash function takes any input — a word, a 4 GB ISO, a database row — and produces a short fixed-length fingerprint. Same input, same fingerprint, every time, on every machine. Change one bit of the input and the output looks completely unrelated. That single property underpins download verification, Git, deduplication, digital signatures, password storage and content addressing, and it also generates a steady supply of security incidents when the wrong function is used for the job. This guide explains what a hash actually guarantees, why MD5 and SHA-1 are still fine for some jobs and disqualified from others, how to verify a download properly, why passwords need an entirely different kind of hash, and what the hash generator here is and is not good for.

The four properties that matter

• Deterministic. The same bytes always produce the same digest. Note bytes: hashing text means hashing a particular encoding of it, so the same word in UTF-8 and UTF-16 gives different digests, and a trailing newline changes everything.
• Fixed length. MD5 is always 128 bits (32 hex characters), SHA-256 always 256 bits (64 hex characters), whether the input was one byte or ten gigabytes.
• Avalanche. Changing a single bit of input changes about half the output bits. There is no partial similarity: two nearly identical files have entirely unrelated digests, which is why hashes cannot tell you how different two things are.
• One-way and collision-resistant. Given a digest you cannot compute the input, and it should be infeasible to find two inputs with the same digest. This is the property that ages: it is a claim about how much computing power an attacker needs, and computing power gets cheaper.

Because the output is fixed-length and the input is not, collisions must exist — there are more possible files than possible 256-bit digests. Security is not about collisions being impossible; it is about them being infeasible to find.

Which algorithm, and what happened to the broken ones

The history is worth knowing because it explains what “broken” means. MD5 collisions were first produced in 2004; by 2007 researchers had chosen-prefix collisions, which let two meaningfully different documents be made to hash identically — and in 2012 the Flame malware used exactly that to forge a code-signing certificate that Windows accepted. SHA-1 fell the same way: Google and CWI produced two different PDFs with the same SHA-1 in 2017, and in 2020 a chosen-prefix collision was demonstrated for an estimated tens of thousands of dollars of rented GPU time — cheap enough that any motivated attacker can afford it.

Crucially, none of this makes MD5 useless for its non-security job. If you want to know whether a file copied across a flaky network arrived intact, MD5 answers that perfectly: random corruption will not produce a matching digest. It only fails when someone is trying to make two files match.

Verifying a download properly

Publishers list a checksum so you can confirm that what arrived is what they published. The mechanics on each platform:

macOS / Linux   shasum -a 256 ubuntu.iso
Linux           sha256sum ubuntu.iso
Windows (PS)    Get-FileHash ubuntu.iso -Algorithm SHA256
Windows (cmd)   certutil -hashfile ubuntu.iso SHA256

Or drop the file into the hash generator here, which computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 in one pass and gives each one a copy button. The file is read by your own browser — it is not uploaded, which is the only sane arrangement for a tool whose whole purpose is confirming you have an untampered copy of something.

Two things people get wrong here:

• Compare the whole digest. Eyeballing the first and last four characters is how a deliberately crafted near-match slips through. Paste both values into a diff, or copy the published one and search for it.
• A checksum on the same page as the download proves less than you think. Whoever can replace the file can usually replace the hash beside it. A checksum is strong protection against a corrupted mirror or a truncated transfer, and weak protection against a compromised publisher. For origin, you want a signature — a GPG-signed SHASUMS file, a signed installer, an OS package manager doing the check for you.

Passwords: a different problem, a different function

Storing passwords as SHA-256 feels responsible and is not. The properties that make SHA-256 excellent for checksums — speed and statelessness — are exactly wrong here. A modern GPU computes billions of SHA-256 digests per second, so a leaked table of unsalted hashes is run through a wordlist and the common passwords fall in minutes. Identical passwords also produce identical hashes, so an attacker instantly sees which accounts share one.

Password storage needs two extra ingredients:

• A per-user salt — random data mixed in before hashing and stored alongside the result. It does not need to be secret, only unique. It kills precomputed rainbow tables and forces the attacker to attack one account at a time.
• Deliberate slowness — a work factor you can raise as hardware improves. Argon2id is the current recommendation (it is memory-hard, so GPUs and custom hardware lose much of their advantage); scrypt and bcrypt remain acceptable. Note bcrypt’s 72-byte input limit if you allow long passphrases.

None of these are on this site’s hash generator, and that is deliberate: a password hash is only meaningful with the parameters your server uses, computed by your server. What the generator is useful for is the other half of the problem — checking that the random password your generator produced is what actually landed in the config file, by comparing digests rather than squinting at characters.

Keyed hashes: HMAC and signatures

A plain hash proves integrity to anyone who has the original. It proves nothing about who produced it, because anyone can compute a hash. Mixing a secret key into the process gives you an HMAC, which proves the message came from someone holding the key — this is what webhook signatures (X-Hub-Signature-256 and friends) and HS256 JWTs use.

HMAC is not simply “hash of key plus message”; it is a specific two-pass construction designed to resist length-extension attacks, which is why you must use a library rather than concatenating things yourself. And it is why a plain digest tool cannot verify a webhook signature or a token: the generator here computes unkeyed digests, which is the right tool for files and the wrong tool for authenticity.

Full digital signatures go one step further with public-key cryptography: the sender signs a hash of the message with a private key, and anyone can verify it with the public one. That is how TLS certificates, signed packages and SSH host keys work — and why the hash algorithm underneath matters so much. A signature over a broken hash is a broken signature, which is precisely how the Flame certificate forgery worked.

Where else hashes turn up

• Git. Every commit, tree and blob is named by the hash of its contents, which is what makes history tamper-evident. Git still uses SHA-1, but with a collision-detection variant that rejects the known attack patterns, and SHA-256 repositories exist for new projects.
• Content addressing and caching. Build tools put a content hash in asset filenames so a changed file gets a new URL and caches never serve stale bytes. HTTP ETags often are hashes.
• Deduplication. Backup systems store each unique block once, keyed by digest. Here a collision would mean silent data loss, which is why serious systems use SHA-256 and not MD5.
• Subresource integrity. <script integrity="sha384-…"> tells the browser to refuse a CDN script whose bytes do not match.
• Breach checks. Password-leak services look up the first five characters of a SHA-1 digest so the full password hash never leaves your machine — a neat trick that only works because hashes are one-way.

Using the generator

Type text into the box and the digests update as you type; the text is encoded as UTF-8 first, so what you get matches what a server computing over UTF-8 bytes would produce. Or click Load File and hash a file instead — the label shows which input the digests belong to, so you can tell at a glance whether you are looking at the file or leftover text.

Two practical notes. The SHA algorithms use the browser’s built-in WebCrypto implementation, which is fast and native; MD5 is not in WebCrypto at all (browsers deliberately do not offer it), so it comes from a small library loaded on first use. And the file is read into memory to hash it, so a multi-gigabyte ISO is better handled by the command-line tools above — for anything up to a few hundred megabytes the browser is comfortable, instant, and does not send your file anywhere.