Understanding file hashes
A fingerprint for every byte.
What a hash does to a file, why every byte matters, and which algorithm to pick for the job in front of you.
What it is.
A cryptographic hash function reads a file from beginning to end and emits a fixed-length number that depends on every byte it saw. Same file in, same hash out. A single bit flipped anywhere in the file produces a hash that bears no resemblance to the original — by design. The function is deterministic and one-way: nobody can run it backwards to recover the file from the digest, even with all the time in the universe.
file → hash(·) → 256 fixed bits
What "every byte" really means.
Hashes don't care about filenames, extensions, modification timestamps, or any filesystem metadata. They see only the byte stream. Two files with identical content and different names will hash identically. A single trailing newline difference will produce a completely different hash. This is the central property — the hash is bound to the content, not the container.
The avalanche effect.
A good cryptographic hash exhibits avalanche: flip one bit of input, and roughly half the bits of the output flip. For SHA-256 that means a 1-bit edit produces a 256-bit output where ~128 bits change in a way that's indistinguishable from random. That's how you can tell a real download from a maliciously-modified one: the hashes don't just differ, they look unrelated.
A worked picture.
The string "The quick brown fox jumps over the lazy dog" hashes (SHA-256) to d7a8fbb3.... Change the period at the end to nothing else and you get ef537f25... — totally different. Add an extra space anywhere and again the hash jumps to something unrelated. There's no continuity; the function discards locality on purpose.
Bit flip
One bit changed in the input
Avalanche turns a tiny edit into a wholly different digest.
"hello" vs "Hello" → completely unrelated SHA-256 outputs
= ~128 bits flipped
SHA-256 — the default choice.
When in doubt, pick SHA-256. It's a member of the SHA-2 family standardised by NIST in 2001, hardware-accelerated on every modern CPU, and the current default for almost every signing, blockchain, certificate and integrity scheme. 256-bit output gives 128 bits of collision resistance — finding two files that hash to the same digest would take 2¹²⁸ operations, comfortably outside any attacker's budget for the next several decades. It's not the fastest hash, but its speed is rarely the bottleneck.
SHA-1 and MD5 — the legacy pair.
MD5 (1992) and SHA-1 (1995) are still encountered everywhere, mostly because they're fast and produce shorter digests — 128 and 160 bits. Both are catastrophically broken for security: practical collision attacks exist against MD5 (any laptop, minutes) and against SHA-1 (Google's 2017 SHAttered demonstration). Use either one for non-security fingerprinting only: deduplicating files where nobody is trying to deceive you, content addressing inside a trusted system, or comparing two locally-controlled copies. Never use them where adversarial input is possible.
SHA-512, BLAKE3, and the newer options.
SHA-512 is the SHA-2 family's larger sibling — same security properties, 64-bit internal state, sometimes faster than SHA-256 on 64-bit CPUs because it processes larger blocks. SHA-3 (Keccak) was standardised in 2015 as a backup family with a completely different internal design — useful for diversity but rarely the right default. BLAKE3, the modern speed champion, runs multiple times faster than SHA-256 on large files and is appropriate when throughput matters and you control both ends; it's not yet standardised by NIST.
Why this runs in your browser.
The browser's Web Crypto API (crypto.subtle.digest) ships native implementations of SHA-1, SHA-256, SHA-384 and SHA-512. Hashing a file locally means the bytes never leave your machine — important for evidence, NDAs, anything you can't upload to a third-party. The tool reads your file as a stream, feeds it through the browser's hardware-accelerated implementation, and renders the resulting hex digest. Large files just take longer; there's no upload bottleneck.
Common uses.
Verify a downloaded ISO or installer against the vendor's published hash. Confirm two backup copies match without re-uploading either. Deduplicate large media libraries by content rather than filename. Generate a content-addressed identifier for git-style storage. Provide a digital evidence integrity record (with a noted timestamp) for legal or forensic purposes. In every case, the property you're leaning on is the same: the hash is bound to every single byte, and nobody can fabricate a different file that produces the same one.