File Hash Verifier

Hashing a file produces a short fingerprint that uniquely identifies its contents. Change one byte and the fingerprint changes completely. This property is what makes hashes useful for the three things that matter: verifying an installer is the one the project published, spotting duplicate files, and detecting bit-rot or tampering.

The classic workflow: you download a Linux ISO, an installer, a cryptocurrency wallet. The project's release page lists a SHA-256 hash next to the download link. You hash your downloaded file and compare. If the hashes match, your file is byte-identical to the file the project published. If they don't, somewhere along the line the bytes changed — maybe the download was interrupted, maybe the mirror you used was compromised, maybe an adversary on your network injected a modified version.

This tool runs that whole comparison in your browser. Drop a file, get five hashes (MD5, SHA-1, SHA-256, SHA-384, SHA-512) computed in parallel. Paste the expected hash into the comparison field; the matching algorithm's row glows green if your file matches. No file ever leaves your tab.

**Which hash should you trust?** The answer depends on whether you're defending against accidents or attackers.

- **Accidents only** (bit flips, truncated downloads, corrupted USB drives): all five algorithms detect these. The cheapest is MD5; the most thorough is SHA-512. The difference is academic for integrity checking. - **Active attackers** (someone trying to swap the file for a malicious version with the same hash): MD5 is broken — a paper from 2008 demonstrated practical collision attacks. SHA-1 is broken — Google demonstrated a collision in 2017. SHA-256 and SHA-512 are not broken; no published attack produces collisions in either. Most modern release-signing infrastructure has migrated to SHA-256.

The recommendation: when a project publishes only a SHA-256 hash, trust the match. When a project publishes MD5 only and you're hashing an installer of a critical app, you can verify the bytes match what they published but you cannot verify nobody got between you and them. That's a deployment problem on the project's end, not yours.

**Performance.** Modern browsers expose Web Crypto, which is a C++ implementation of SHA-1/256/384/512 inside the browser engine. It runs at roughly disk-read speed — hashing a 1 GB file takes about as long as reading the file. The bottleneck is I/O, not computation. MD5 is the slow one here because Web Crypto doesn't expose it (Mozilla and Chromium consider it cryptographically broken enough not to expose); we use **spark-md5** in pure JS for it, which is roughly 3–5x slower per byte than native code. Even so, hashing a 200 MB file with MD5 takes only a few seconds. For larger files, MD5 will lag behind the others — that's expected.

For very large files (over ~2 GB) we read in 2 MB chunks at a time rather than loading the whole file into memory at once. The streaming pattern means a 10 GB file doesn't blow up the tab; the practical ceiling is the OS file size limit and the browser's per-tab memory cap.

**Edge cases handled correctly.**

- **Empty file.** All five algorithms produce well-defined hashes for the empty input (the MD5 of an empty file is famously `d41d8cd98f00b204e9800998ecf8427e`, which is a fingerprint you'll see again in many places). The tool handles empty files without special-casing. - **Files larger than memory.** The streaming chunk pattern means you can hash a file bigger than your free RAM, as long as the OS lets the browser read it. - **Files with non-ASCII names.** Names like `résumé.pdf` or `東京.txt` work fine — the file system layer handles the names; the hash is over the bytes inside, regardless of filename. - **Files served from drag-and-drop vs file-input.** Both paths produce the same hashes because both produce the same `File` object with the same bytes underneath. - **Whitespace / formatting in the expected hash.** `abcd1234` and ` abcd1234` and `abcd1234 *filename.zip` all compare equal because the tool trims whitespace and strips trailing `* filename` artifacts before comparison. (`sha256sum` output on Linux looks like `<hash> <filename>` and we accept that format.)

**Privacy is the whole point.** Every existing online hash tool sends your file to their server. That's fine for public files but obviously wrong for anything sensitive — a private backup, a confidential document, an in-progress release build, password databases, encryption keys. This tool never uploads. The hashing happens inside your browser process via Web Crypto (a browser primitive) and spark-md5 (a JS library in this page's bundle). The network panel is empty during operation; verify it yourself. The whole experience is functionally identical to running `sha256sum file.iso` at a terminal, except in a browser tab that you didn't have to install anything to use.

**One thing this tool does not do:** signature verification. A hash tells you "the bytes match what was published." A *signature* tells you "the bytes were published by someone holding the signing key." For signature verification (GPG, Sigstore, code signing), use a dedicated tool like `gpg --verify`. Hashing alone proves integrity given that you trust the source of the expected hash.