A hash is a fingerprint, not a lock
It's easy to confuse hashing with encryption because both scramble data into unreadable-looking output, but they solve completely different problems. Encryption is reversible — with the right key, you get the original data back, and its purpose is confidentiality. A cryptographic hash is one-way: there's no key, no way to reconstruct the original file from its digest, and that's by design. Its purpose isn't hiding data, it's fingerprinting it — producing a fixed-length string that changes completely if even a single byte of the input changes, giving you a compact, reliable way to check whether two files are byte-for-byte identical without comparing every byte directly.
This is exactly why file verification uses hashing rather than encryption: you're not trying to protect the file's contents, you're trying to confirm the file you have is exactly the file that was published, with nothing added, removed, or corrupted along the way.
Why compute all three algorithms instead of just one
| Algorithm | Status | Typical use |
|---|---|---|
| SHA-1 | Older, collision-vulnerable | Still widely used in Git and legacy certificate fingerprints |
| SHA-256 | Modern default | The most common standard for file integrity checks today |
| SHA-512 | High-security preference | Used where a longer digest and extra margin matters |
Checking a file's hash
Drop a file — up to 512 MB, any file type — onto the upload zone.
Wait for SHA-1, SHA-256, and SHA-512 to be computed using crypto.subtle.digest.
Copy any digest with the Copy button next to it.
Paste an expected hash and pick which algorithm to compare against to verify integrity.
Why three algorithms are computed even though you'll usually only need one
Different publishers and systems standardize on different algorithms, and you don't always get to choose which one you're handed. Git still relies on SHA-1 internally for commit identifiers, some legacy certificate fingerprints are published in SHA-1, most modern software downloads publish SHA-256, and high-security contexts sometimes specify SHA-512 for its larger digest size. Rather than making you guess which algorithm a given published reference hash uses and re-running the tool if you guessed wrong, computing all three upfront means whatever reference hash you're handed, there's already a matching digest ready to compare against.
The canonical verification workflow
How the match check actually works
When you paste an expected hash, the tool normalizes both strings — converting to lowercase and trimming whitespace — before comparing them byte-for-byte. This normalization matters because hash digests are often displayed with inconsistent capitalization or extra surrounding whitespace depending on where they were copied from, and a mismatch caused purely by formatting differences would be a false negative, incorrectly suggesting file corruption when the actual bytes are identical. A green result means the digests match exactly after normalization; a red result means they genuinely differ, which is the real signal that the file may have been modified or corrupted.
Why file size has a practical limit
The tool supports files up to 512 MB, and that ceiling exists because the entire file has to be read into browser memory before crypto.subtle.digest can process it — there's no streaming or chunked hashing happening under the hood. For most downloads this is more than enough headroom, but very large files (multi-gigabyte disk images, large datasets) can strain memory on lower-end devices even before hitting the 512 MB cap. For files beyond what's practical here, a native command-line tool like sha256sum handles arbitrarily large files more efficiently since it can stream the file from disk rather than loading it entirely into memory first.
Common mistakes
Comparing against the wrong algorithm's published hash — check which algorithm the publisher actually used before assuming a mismatch means corruption.
Assuming a hash mismatch could be fixed by re-copying the reference hash more carefully — the normalization already handles case and whitespace differences, so a genuine mismatch reflects an actual byte-level difference in the file.
Trying to hash a multi-gigabyte file and hitting memory strain — for very large files, a native command-line hashing tool is the more practical choice.
Treating a matching hash as proof of the file's safety in every sense — a matching digest confirms the file wasn't altered from what the publisher released, but it doesn't independently vouch for whether the publisher's original file itself was trustworthy.
Real use cases
Verifying a downloaded software installer or disk image against the publisher's posted SHA-256 before running it.
Confirming two copies of a file on different devices or drives are genuinely identical.
Checking a large file transfer completed without corruption by comparing hashes before and after.
Generating a reference digest for a file you're distributing, so recipients can verify their download later.
Frequently asked questions
Q: Is my file uploaded?
A: Never. The file is read in your browser and digested locally with crypto.subtle.digest, with zero upload requests.
Q: Why three algorithms?
A: SHA-1 is older and collision-vulnerable but still widely used in Git and legacy certificate fingerprints. SHA-256 is the modern default. SHA-512 is preferred for high-security contexts. Computing all three lets you compare against whichever reference you're given.
Q: How big a file can I hash?
A: Up to 512 MB. The full file is read into memory for the digest call, so very large files may strain low-end devices — for multi-GB files, use a native tool like sha256sum.
Q: What's the difference between a hash and an encryption?
A: A hash is one-way — you cannot recover the file from the digest. It's used for integrity verification (did the bytes change?) and fingerprinting, not confidentiality.
Q: How is the verify-match check done?
A: Both strings are normalized — lowercased and trimmed of whitespace — then compared byte-for-byte. A green result means the digests are identical; a red result means they differ, which may indicate the file was modified or corrupted.
Q: Can I use this to verify a download?
A: Yes — that's the canonical use case. The publisher posts a SHA-256, you download the file, run it through this tool, and confirm the digests match.
Check your file now
Verify a file's integrity with the File Checksum tool. Need to protect a file's contents rather than just verify them? Try Encrypt & Decrypt Text or Secure Notes. Checking a website's certificate instead? See the SSL Certificate Decoder.
