File Hash Verification Tool
Calculate MD5, SHA-1, SHA-256, SHA-384, SHA-512 hashes for files
Drag and drop file here
Supports any file type and size
What is File Hash?
A file hash turns the contents of a file into a fixed-length digest using a chosen algorithm. The same file produces the same value every time, while even a one-byte change can produce a completely different result. Hashes help verify downloads, compare backups, detect duplicates, check transfer integrity, and match security advisories or release checksums. This tool supports algorithms such as MD5, SHA-1, SHA-256, SHA-384, and SHA-512. MD5 and SHA-1 still appear in legacy workflows, but they are not appropriate for modern security guarantees; SHA-256 or stronger algorithms are usually preferred when integrity matters. The hash cannot be reversed into the original file.
How to Use
How to use
- Drag a file to the upload area or click 'Select File' button
- Check the hash algorithms you want to calculate (multiple selections)
- Click 'Calculate Hash' button to start
- After calculation, copy individual hash values or all at once
- For verification, enter a known hash value in the comparison field
Verification Workflow
- Calculate the hash after the file is fully downloaded or copied; partial files and transfer interruptions produce different values.
- When comparing with a published checksum, copy it from the official source and match the algorithm exactly.
Use Cases
Technical Principle
All SHA digests in the page run through the W3C Web Cryptography API, exposed in the browser as crypto.subtle. The call site is await crypto.subtle.digest(algorithm, buffer), where algorithm is one of 'SHA-1', 'SHA-256', 'SHA-384', or 'SHA-512' (case-sensitive) and buffer is an ArrayBuffer or any TypedArray. The function returns a Promise that resolves to an ArrayBuffer of the digest bytes, which the page converts to lowercase hexadecimal by walking it as a Uint8Array and mapping each byte to byte.toString(16).padStart(2, '0'). SubtleCrypto is only available in secure contexts (HTTPS or localhost), and SHA-1 is intentionally kept available for legacy verification while the spec calls it out as cryptographically broken for collision resistance. MD5 is not in the Web Crypto specification (the W3C deliberately omitted it because of collision attacks), so MD5 in this page is computed by a pure-JavaScript implementation that runs entirely in the browser. For every algorithm — MD5 and the SHA family alike — the file is read as an ArrayBuffer in one shot via FileReader.readAsArrayBuffer, then handed to either the JavaScript MD5 routine or crypto.subtle.digest. There is no incremental .append API and no Web Worker fallback in this tool, so memory has to fit the whole file at once: that is fine for typical downloads but not ideal for multi-gigabyte payloads, where a desktop tool that streams from disk (sha256sum, certutil -hashfile, Get-FileHash) is the better fit. Digest lengths and security posture: MD5 = 128 bits / 32 hex chars (RFC 1321, collision-broken since Wang Xiaoyun 2004, exploited in the wild by Flame malware in 2012); SHA-1 = 160 bits / 40 hex chars (FIPS 180-4, collision shown by Google's SHAttered in 2017 at ~9.2 quintillion SHA-1 computations, formally deprecated by NIST after 2030); SHA-256 = 256 bits / 64 hex chars (FIPS 180-4, no known collisions, the recommended baseline); SHA-384 and SHA-512 = 384 / 512 bits, the truncated and full output of the SHA-512 family (FIPS 180-4). The avalanche property of cryptographic hashes means flipping a single bit of input changes roughly half the output bits on average, which is why a one-byte file edit produces a completely different digest.
- crypto.subtle.digest(algorithm, buffer) accepts 'SHA-1', 'SHA-256', 'SHA-384', 'SHA-512' (case-sensitive) and rejects 'MD5'; requires a secure context (HTTPS or localhost) and returns a Promise<ArrayBuffer>.
- Hex encoding: walk the result as new Uint8Array(digestBuffer) and map each byte to byte.toString(16).padStart(2, '0'); compare digests case-insensitively (normalize via .toLowerCase()).
- MD5 is absent from Web Crypto by design; this tool computes MD5 in pure JavaScript, reading the file as a single ArrayBuffer via FileReader.readAsArrayBuffer and producing a 32-character lowercase hex digest in one pass.
- Memory profile: the page reads the whole file into a single ArrayBuffer (no incremental .append API and no Web Worker offload) and hands the buffer to either JavaScript MD5 or crypto.subtle.digest in one call. For files that exceed the tab's available heap, switch to a desktop tool (sha256sum, certutil -hashfile, Get-FileHash) that streams from disk.
- Digest sizes (FIPS 180-4): MD5 128-bit, SHA-1 160-bit, SHA-256 256-bit, SHA-384 384-bit, SHA-512 512-bit; hex char count is twice the byte count.
- Known collision attacks: MD5 broken by Wang 2004, exploited by Flame 2012; SHA-1 broken by Google SHAttered 2017 (~9.2 × 10^18 ops, ~110 GPU-years); SHA-256 and above have no known practical collisions.
- Avalanche effect: a single-bit input change flips ~50% of output bits on average; this is why a one-byte edit produces a completely different hex digest and why partial-file matches do not exist.
Examples
Verify a downloaded file against a published checksum
File: sample.bin (3 bytes, contents: abc)
SHA-256 (computed):
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
Publisher's published SHA256SUMS line:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad sample.bin
Match -> download is intact, not tampered with
(Both values are the FIPS 180-2 SHA-256 reference vector for the
3-byte input 'abc'. Replace the input with the real file in
practice; the algorithm output is deterministic.)Multi-algorithm comparison on the same input
File: sample.txt (3 bytes, contents: abc)
MD5: 900150983cd24fb0d6963f7d28e17f72
SHA-1: a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-512: ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
Different algorithms, same input -> use SHA-256 or stronger for security checks
(MD5 is the RFC 1321 reference vector; the others are FIPS 180-2
reference vectors, all for the 3-byte input 'abc'.)Detect a 1-byte change (avalanche effect)
Input A: abc (3 bytes)
Input B: abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq (56 bytes)
SHA-256 of A: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-256 of B: 248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1
A small change in the input produces a completely different
digest -> this is the avalanche effect at work.
(Both values are FIPS 180-2 SHA-256 reference vectors.)Browser console reference for verification
// Reproduce in Node.js for comparison
$ printf 'abc' | shasum -a 256
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
// PowerShell on Windows
PS> 'abc' | Get-FileHash -Algorithm SHA256 | Select-Object -ExpandProperty Hash
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
// In the browser console, using the Web Crypto API:
// const buf = new TextEncoder().encode('abc');
// const hash = await crypto.subtle.digest('SHA-256', buf);
// -> ArrayBuffer of the SHA-256 of 'abc' (FIPS 180-2 reference vector)
Files stay in your browser, nothing uploaded.FAQ
Which hash algorithms can I generate?
Common options are MD5, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The page computes them via the browser's Web Crypto API (SHA family) and built-in JS for MD5. SHA-256 is the recommended general-purpose choice today.
Is the file uploaded anywhere?
No. Hashing happens entirely in your browser using the File API and Web Crypto. The bytes are read into memory in chunks and the hash is computed locally - the file does not cross the network. You can verify by checking the Network tab while you hash a file.
Why is MD5 still offered if it is broken?
MD5 is broken for security purposes (collisions are easy to construct) but remains the de-facto checksum for verifying that a download is bit-identical to the source - many vendors still publish MD5 alongside SHA-256. Use MD5 only for that, never for password hashing or signatures.
Why are my SHA-256 hashes different for the same-looking file?
Hash inputs include every byte, so a single trailing newline, BOM, or different line ending (CRLF vs LF) changes the hash completely. Re-download the original instead of copy-pasting, or use a binary file viewer to confirm both files have identical bytes.
Is there a file size limit?
The browser must hold enough memory to read the file. Modern desktops handle multi-GB files, but mobile browsers may run out of memory around a few hundred MB. For very large files, use a desktop tool (sha256sum, certutil, Get-FileHash) - it streams from disk and is faster.
Can two different files produce the same hash?
In theory yes (the pigeonhole principle), but for SHA-256 the chance is astronomically low. MD5 and SHA-1 have known collision attacks, so two files with the same MD5 or SHA-1 do not prove they are the same file. SHA-256 collisions are not feasible with known attacks.
Why do my hashes differ from the website's published hash?
Most often: you downloaded a localised, signed, or repackaged version; the page lists the hash for a different version; or your download was truncated. Re-download with a fresh tool, then re-hash. If the mismatch persists, do not trust the file.