SHA Hash Generator

What a hash gives you

A cryptographic hash turns any input into a fixed-length fingerprint. The same input always gives the same digest, a one-character change scrambles the whole thing (the "avalanche" effect), and you can't run it backwards to recover the input. Output sizes:

The avalanche effect, concretely

SHA-256 of hello begins 2cf24dba5fb0a30e…. Change one letter to Hello and the digest becomes 185f8db32271fe25… — completely different, with no resemblance to the first. One flipped input bit changes about half the output bits. That is what lets a hash detect the tiniest change to a file, and why you cannot work backwards from a digest to its input.

Hashing in different languages

# Command line
echo -n "hello" | sha256sum

# Python
import hashlib
hashlib.sha256(b"hello").hexdigest()

// JavaScript (browser)
const buf = await crypto.subtle.digest(
  "SHA-256", new TextEncoder().encode("hello"));
const hex = [...new Uint8Array(buf)]
  .map(b => b.toString(16).padStart(2, "0")).join("");

What hashes are good for

• File integrity — compare a download's SHA-256 against the published checksum to confirm it was not corrupted or tampered with.
• Deduplication and caching — using a content hash as a key, so identical content maps to the same entry.
• Fingerprinting — telling whether two pieces of data are the same without comparing them byte by byte.

Why you can't just SHA a password

This is the mistake that leaks a million accounts at a time. SHA-256 was designed to be fast, and a modern GPU computes billions of them a second. Point that at a stolen table of SHA-256 password hashes and an attacker grinds through every common 8-character password in hours, not years. The speed that makes SHA great for checksums makes it useless for passwords.

Password hashing wants the opposite of fast: deliberately slow, memory-hungry, and salted. A salt is a random value stored next to each hash so two people with the same password still get different hashes, which kills the precomputed "rainbow tables" attackers keep on hand. You don't build this yourself — you use bcrypt, scrypt, or Argon2 (the current first choice), which bake in the salt and a tunable cost you can crank up as hardware gets faster. If you find sha256(password) anywhere near a login, treat it as a security bug, not a style preference.

HMAC: proving who sent something

A plain hash tells you a file hasn't changed. It can't tell you who produced it, because anyone can recompute it. HMAC closes that gap by folding a secret key into the hash, so only someone holding the key can generate a valid tag. It's everywhere once you look: webhook providers like Stripe and GitHub send a signature header you verify with HMAC-SHA256 to confirm the request really came from them, signed API requests use the same idea, and the HS256 flavour of a JWT is HMAC under the hood. Same SHA doing the work, plus a key — and that key is the entire difference between "this data is intact" and "this data came from someone I trust".