What is a hash function?

A hash function is a one-way compression: it takes data of any size — a single character or a 40 GB disk image — and produces a fixed-size fingerprint called a digest. SHA-256 always outputs exactly 256 bits (64 hex characters), whatever went in. Three properties make it useful:

• Deterministic. The same input always gives the same digest, on any machine, in any language. That is what makes hash comparison a reliable integrity check.
• One-way. Given the digest, recovering the input is computationally infeasible. You can verify that a file matches a hash, but you cannot work backwards from the hash to the file.
• Avalanche. Changing one bit of the input changes roughly half the bits of the output, unpredictably. There is no “close” hash for a “close” file — a one-byte difference in a 1 GB ISO produces a completely different SHA-256.

The SHA family, compared

Algorithm	Output	Status	Typical use
SHA-1	160 bits (40 hex)	Broken for collision resistance (practical collision demonstrated in 2017, “SHAttered”). Still widely seen in legacy systems and in git’s commit IDs, where it is not used as a security boundary.	Legacy compatibility only. Do not choose it for anything new.
SHA-256	256 bits (64 hex)	Secure. The default cryptographic hash in TLS, blockchain, password KDFs and file verification. No practical attacks known.	The safe default for almost everything: download verification, checksums, API signatures, deduplication.
SHA-384	384 bits (96 hex)	Secure. Same core as SHA-512 with a different starting state.	Rarely needed on its own; occasionally required by specific protocols or vendors.
SHA-512	512 bits (128 hex)	Secure. Often faster than SHA-256 on 64-bit hardware because it processes 1024-bit blocks with native 64-bit operations.	Large files on 64-bit systems, and anywhere a longer digest is wanted (more margin against brute force).

You will also meet MD5 (128-bit) and CRC-32. MD5 is cryptographically broken and should not be used where integrity matters; CRC-32 is a fast error-detection code, not a cryptographic hash — collisions are easy to manufacture on purpose. If a tool offers MD5 and you do not specifically need it for compatibility, use SHA-256 instead.

Hashing is not encryption

People use the words interchangeably, but the two operations are opposites in one important way:

	Encryption	Hashing
Reversible?	Yes — with the key, you get the original data back	No — there is no key that undoes it; the input cannot be recovered
Output size	Same order as the input (plus padding)	Fixed, regardless of input size
Purpose	Keep data secret from people without the key	Prove data is unchanged (or identify it) without revealing it
Example	AES-256 encrypting a database file	SHA-256 of a downloaded ISO, compared against the vendor’s published value

The classic application is password storage: a site stores the hash of your password, not the password. At login it hashes what you typed and compares. An attacker who steals the database still cannot read your passwords — only guess them. (Production systems add a per-user salt and a deliberately slow key derivation function such as bcrypt or Argon2, because fast hashes like raw SHA-256 let attackers try billions of guesses per second.)

Why one typo changes everything

The avalanche effect is not a bug — it is the whole point. If similar inputs produced similar hashes, an attacker could take a valid file, tweak one byte, and search for a tweak that kept the hash the same. SHA-256’s internal compression function mixes every input bit through 64 rounds of non-linear operations, so a one-bit change propagates into roughly 50% of the output bits with no detectable pattern. Try it above: flip the last character of your text and watch every digest change almost completely.

Where you meet hashes every day

• Download verification. Linux distros, browsers and game launchers publish SHA-256 checksums so you can prove your download arrived intact and unmodified.
• Git. Every commit ID is a SHA-1 hash of the commit’s contents, parents, author and timestamp — change anything and the ID changes, which is how git detects tampering and corruption.
• Package managers. pip, npm and cargo record hashes of dependencies in lockfiles so a re-install fetches byte-identical packages.
• Blockchains. Each block contains the hash of the previous one; altering any historical block would invalidate every hash after it.
• Deduplication. Backups and sync tools hash files to skip ones they already have.

Which algorithm should you use?

SHA-256 for almost everything — it is the interoperable default and every tool supports it. SHA-512 if you are hashing very large files on a 64-bit machine (it is often faster) or a protocol asks for 512 bits. SHA-384 only when a spec requires it. Avoid SHA-1 and MD5 for anything new; use them only to interoperate with systems that still expect them.

Hash and verify files from the command line

For everyday work the shell tools are hard to beat — they stream the file, so even huge files are fine:

# Linux / macOS
sha256sum file.iso                 # print the SHA-256
shasum -a 256 file.iso             # macOS alternative
sha256sum -c file.iso.sha256       # verify against a published checksum file

# Windows PowerShell
Get-FileHash file.iso -Algorithm SHA256
(Get-FileHash file.iso).Path       # …and compare

The Files tab above exports exactly the sha256sum -c format — copy it, save it next to your files, and any Linux box can re-verify them later.

Nothing on this page leaves your browser: there is no server round-trip when you type, paste or drop a file, no analytics on your inputs, and no storage of any kind.