How to Generate MD5 and SHA-256 Hashes:
Step-by-Step Tutorial

This tutorial shows you how to generate an MD5 or SHA-256 hash from any text, verify a downloaded file against a published checksum, and pick the right algorithm for the job. Hashing a string takes ten seconds; knowing which algorithm to trust is the part worth reading.

Step 1: Hash a String

Open the Hash Generator, paste or type your text, and read off the hashes. Everything is computed locally in your browser. For the input hello:

MD5:     5d41402abc4b2a76b9719d911017c592
SHA-1:   aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Three properties to notice. The output length is fixed regardless of input size — SHA-256 always produces 64 hex characters (256 bits), whether you hash one word or a 4 GB file. The same input always yields the same hash. And the function is one-way: there is no "decode" operation.

Step 2: See the Avalanche Effect

Change one character — hash Hello instead of hello:

SHA-256 of "hello":
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-256 of "Hello":
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

The two outputs share nothing. This is the avalanche effect, and it's why a hash detects even a single flipped bit in a large file — and also why "the hashes look similar" is never a thing: hashes either match exactly or mean nothing.

Step 3: Pick the Right Algorithm

Algorithm	Output	Status	Use for
MD5	128-bit / 32 hex	Broken for security	Non-security checksums, cache keys, deduplication
SHA-1	160-bit / 40 hex	Broken (collisions demonstrated 2017)	Legacy compatibility only (e.g. Git's internal IDs)
SHA-256	256-bit / 64 hex	Secure	File integrity, signatures, general security
SHA-512	512-bit / 128 hex	Secure	Same as SHA-256; faster on 64-bit CPUs

The practical rule: SHA-256 by default. MD5 remains acceptable where an attacker gains nothing from forging a collision — detecting accidental corruption, generating cache keys — but never where someone might deliberately craft a matching input. And none of these, including SHA-256, is appropriate for storing passwords; that's a different job covered below.

Worked Example: Verifying a Downloaded File

You download an installer, and the project page publishes:

SHA-256: 8f43…a1b2  ubuntu-24.04-desktop-amd64.iso

Verify before running it:

1. Compute the file's hash locally (commands in the next section — for large files, use the terminal rather than a browser tool).
2. Compare with the published value. Don't eyeball all 64 characters — paste both into the Diff Checker, or compare the first and last 8 characters, which is sufficient against accidental corruption.
3. Match → the file is bit-for-bit what the publisher hashed. Mismatch → the download is corrupted or tampered with; delete and re-download from the official source.

One caveat: a checksum published on the same page as the download only proves integrity, not authenticity — an attacker who replaced the file could replace the checksum too. Projects that take this seriously also publish PGP signatures.

Hashing Without the Tool

# macOS
shasum -a 256 file.iso
md5 file.iso

# Linux
sha256sum file.iso
md5sum file.iso

# Windows PowerShell
Get-FileHash file.iso -Algorithm SHA256

# Hash a string (mind the -n: echo's newline changes the hash!)
echo -n "hello" | shasum -a 256

# Node.js
node -e "console.log(require('crypto').createHash('sha256').update('hello').digest('hex'))"

# Python
python3 -c "import hashlib; print(hashlib.sha256(b'hello').hexdigest())"

The -n flag deserves emphasis: echo "hello" pipes six bytes (hello\n), not five, and produces a completely different hash. If your shell-computed hash never matches the tool's, this is why.

Common Problems and Fixes

Same text, different hash in two tools

The bytes differ even though the visible text matches: a trailing newline or space, Windows \r\n vs Unix \n line endings, or different Unicode encodings (UTF-8 vs UTF-16 — PowerShell pipes default to UTF-16). Hash functions hash bytes, not characters. Normalize line endings and strip whitespace, then retry.

Trying to "decrypt" a hash back to the original

Not possible — hashing discards information irreversibly. What attackers actually do is guess-and-check: hash billions of candidate inputs and compare (rainbow tables, brute force). Short or common inputs fall quickly this way, which is why unsalted fast hashes are unsafe for passwords.

Using SHA-256 for password storage

A GPU computes billions of SHA-256 hashes per second — great for checksums, catastrophic for passwords, because it makes guessing cheap. Password storage needs a deliberately slow, salted algorithm: bcrypt, scrypt, or Argon2. Try the Bcrypt Hash tool to see the difference; the password and hash guide explains the economics.

Need a hash that proves who created it

A plain hash proves integrity, not origin — anyone can hash anything. To bind a hash to a secret key (webhook signatures, API request signing), use HMAC: the HMAC Generator computes HMAC-SHA256(key, message), verifiable only by holders of the key.

FAQ

Can two different inputs produce the same hash?

In theory yes (infinitely many inputs map to finitely many outputs), but for SHA-256 no collision has ever been found — with 2²⁵⁶ possible outputs, random collision probability is negligible beyond imagination. MD5 and SHA-1 are different stories: collisions can be manufactured on demand, which is precisely why they're retired from security use.

Is MD5 ever OK to use?

Yes — where no adversary is involved. Detecting accidental file corruption, building cache keys, bucketing data for deduplication: MD5 is fine and fast. The rule of thumb: if a malicious actor forging a collision would matter, MD5 is disqualified.

What's the difference between hashing and encryption?

Direction. Encryption is reversible with the key — encrypt, send, decrypt. Hashing is one-way by design — there is nothing to reverse and no key. Use encryption (like the AES tool) to protect data you need back; use hashing to fingerprint data you only need to compare.

Why does Git still use SHA-1?

Git uses SHA-1 as a content address, not a security boundary, and has collision-detection mitigations built in since 2017. The project has been migrating toward SHA-256 object formats, but compatibility keeps SHA-1 the default. It's a good example of context deciding whether a "broken" hash is actually a problem.