- Which hash should I use — MD5, SHA-1, or SHA-256?
- For verifying a download or a file you control, any of the three works — they're all sensitive enough that a single bit-flip changes the digest completely. For anything security-sensitive (signed releases, certificates, anti-tampering checks), use SHA-256. MD5 and SHA-1 are both considered broken against collision attacks: an attacker who controls the file's contents can construct two different files with the same MD5 or SHA-1, so they're no longer safe for proving 'this file is the one the vendor signed.' SHA-256 has no known collision attacks.
- Why are all three hashes shown at once?
- Most checksum files publish only one — usually SHA-256 today, sometimes SHA-1 or MD5 for legacy reasons. Computing all three at once means you don't need to know in advance which one the vendor published; paste whichever they list and the tool picks the right algorithm to compare against by the length.
- Are my files uploaded anywhere?
- No. Hashing runs entirely in your browser using the Web Crypto API (for SHA-1 and SHA-256) and a pure-JavaScript MD5 implementation. Nothing is sent over the network, nothing is logged, nothing is stored. Close the tab and the file is gone from the tool's memory.
- What's the largest file I can hash?
- The tool reads the file into memory before hashing, so the practical limit is whatever your browser can fit in a single ArrayBuffer — typically 1-2 GB on a modern desktop, less on mobile. For files larger than that you'd want a streaming hash (one block at a time), which most desktop tools (sha256sum, certutil, Get-FileHash) handle natively.
- How do I get the official hash to compare against?
- Most projects publish hash files alongside their downloads. Look for a file ending in .sha256, .sha256sum, SHA256SUMS, .md5, or CHECKSUMS in the same directory as the download. Open it in a text editor and you'll see the hex digest followed by the filename. Paste the hex digest into the Expected field here.
- The hashes don't match — what now?
- Three possibilities, in order of likelihood: the file got corrupted in transit (re-download from a stable mirror), you have a different version of the file than the hash describes (check the file's release date and version number), or in the worst case the file has been tampered with (re-download from the vendor's verified-HTTPS site and check the hash against the one they sign with PGP). Don't run an executable whose hash doesn't match.
- Why does the same file produce a different hash on a different machine?
- It shouldn't — that's the definition of a hash. If you're seeing different results, the most common cause is that one machine downloaded a slightly different file (different line endings on text files, different mirror serving a stale version, a partial download that got resumed). Re-download and re-hash to confirm.
- Can I use this to check that a file I uploaded matches what arrived at the other end?
- Yes — that's the standard use case. Hash the file before sending, send the file plus the hash separately, and have the recipient hash on their end and compare. If the hashes match the file is byte-for-byte identical. This is exactly what package managers (apt, yum, brew, pip) do under the hood to verify every download.
