How File Hashing Verifies Integrity and Which Algorithm to Use
A file hash checksum verifier calculates a fixed-length fingerprint of any file you choose, then lets you compare that fingerprint against a value someone else published, like a checksum listed next to a Linux ISO download or a firmware file from a router vendor. The fingerprint, called a hash, changes completely if even a single byte in the file is different, which makes it a reliable way to confirm a download finished intact and was not corrupted or tampered with in transit. Developers, system administrators, and anyone who downloads software from the internet use tools like this before running an installer or flashing a device, because a mismatched hash is the clearest signal that something went wrong with the file.
This tool supports six algorithms: MD5, SHA-1, SHA-256, SHA-384, SHA-512, and CRC32. The browser's built-in Web Cryptography API computes SHA-1 through SHA-512 directly via crypto.subtle.digest(), while MD5 comes from a small local library since the W3C deliberately left MD5 out of WebCrypto due to its known collision weaknesses. CRC32 is implemented from scratch as a table-based lookup using the standard IEEE 802.3 polynomial 0xEDB88320 in reflected form, the same algorithm used by zip files and Ethernet frame checks. The file itself is read in chunks with file.slice(), updating a progress bar as each chunk loads, rather than pulling the entire file into memory in one call. That said, crypto.subtle.digest() is not a streaming API, so the full buffer still has to exist in memory at the moment the hash is calculated.
Consider verifying the SHA-256 hash of the exact three-byte text abc: the RFC-documented result is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, and hashing an empty zero-byte file produces e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If a publisher lists a value next to a download and your computed hash matches it exactly after the tool normalizes both strings to lowercase and trims whitespace, you get a large green PASS with a checkmark. Paste in a different string, even one character off, like an accidentally truncated hash, and you get a clear red FAIL, because a checksum comparison has no concept of close enough. The tool also auto-detects which algorithm you likely copied based on the pasted string's length: 32 hex characters implies MD5, 40 implies SHA-1, 64 implies SHA-256, 96 implies SHA-384, and 128 implies SHA-512.
System administrators use this before deploying a Linux distribution ISO to a fleet of servers, confirming the SHA-256 published on the distro's official site matches what actually downloaded, since a compromised mirror could silently swap in a malicious image. Developers verify npm package tarballs, Docker image layers, or firmware binaries from IoT vendors the same way, especially when a project ships checksums in a release notes page precisely so users can catch tampering. Digital forensics investigators hash evidence files at intake and again before presenting them in court, since a matching hash is often the technical basis for proving a copy was not altered. Regular users comparing two copies of a large video or backup archive, perhaps one on a USB drive and one in cloud storage, can hash both and see instantly whether they are byte-for-byte identical without opening either file.
A common mistake is treating MD5 or CRC32 matches as proof of authenticity rather than accidental-corruption detection: both algorithms are fast but cryptographically broken, meaning a determined attacker can craft a different file with the same MD5 or CRC32 value, so use SHA-256 or higher whenever the file's integrity actually matters for security rather than just catching a bad download. Because crypto.subtle.digest() needs the complete file in memory to compute a hash, files above roughly 500 MB may be slow or fail outright depending on how much RAM your browser tab has available, especially on mobile devices, so treat that as a practical ceiling rather than a hard limit. Every byte of your file stays on your device: nothing is uploaded anywhere, the hashing runs entirely through your browser's built-in WebCrypto engine and a small local CRC32 and MD5 implementation, and closing the tab discards everything.