Free File Hash Calculator

What File Hashes Actually Are

A cryptographic hash is a fixed-length fingerprint computed from arbitrary input data (a file, a string, a stream of bytes) using a deterministic mathematical function. Every distinct input produces a different output (with vanishingly small collision probability for modern hash functions); flipping a single bit anywhere in a multi-gigabyte file changes essentially every bit of the resulting hash. The function runs only one direction: from input you can compute the hash trivially, but recovering the input from the hash is computationally infeasible for any decent hash function. The output is always the same fixed length regardless of input size, SHA-256 produces 256 bits (32 bytes, displayed as 64 hex characters) whether the input is one byte or one terabyte. Three properties matter: preimage resistance (you cannot reverse-engineer a file from its hash), second-preimage resistance (you cannot construct a different file with the same hash), and collision resistance (you cannot find any two distinct files with matching hashes). This editor calculates the hash of any file you provide using the browser's built-in Web Crypto API: specifically SubtleCrypto.digest(), which is implemented natively in every modern browser and runs on the device's CPU rather than uploading the file anywhere.

The Algorithms, A Brief History

Five algorithms in this tool, in chronological order of release. MD5 (Message Digest 5, Ronald Rivest at MIT, RFC 1321 published April 1992) produces a 128-bit hash and was the dominant general-purpose hash for the 1990s and early 2000s. Cryptographic weaknesses started appearing in 1996 (Dobbertin's pseudo-collision); a practical collision attack was demonstrated by Xiaoyun Wang and Hongbo Yu in August 2004 at CRYPTO 2004, completed in under an hour on a single machine. Marc Stevens published a chosen-prefix collision attack in 2008 that allowed forging colliding X.509 certificates. MD5 is now broken for any cryptographic purpose, never use it where collision resistance matters (digital signatures, certificate fingerprints, password hashing). It remains useful for non-cryptographic integrity checks (detecting accidental corruption from bad disks or noisy network transfers) and for content-addressable identifiers where you trust the source not to be malicious.

SHA-1 (Secure Hash Algorithm 1, designed by the NSA, published as FIPS 180-1 in April 1995) produces a 160-bit hash and was the dominant cryptographic hash for the late 1990s through the early 2010s. Theoretical attacks were proposed in 2005 by Wang, Yin and Yu. The first practical SHA-1 collision was published on 23 February 2017 by a Google + CWI Amsterdam team led by Marc Stevens (the "SHAttered" attack) using around 9 quintillion SHA-1 computations to produce two PDF files with identical SHA-1 hashes but visibly different content. Browsers had already started phasing out SHA-1 TLS certificates by then; modern Git is migrating from SHA-1 to SHA-256 for object identity. Like MD5, SHA-1 is fine for non-cryptographic integrity but should never be used where collision resistance matters in 2026.

SHA-2 (NSA, FIPS 180-2 published August 2002) is the current workhorse hash family, a set of related functions including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. SHA-256 produces 256-bit hashes, SHA-384 produces 384-bit hashes, SHA-512 produces 512-bit hashes; 384 is essentially SHA-512 with truncated output and a different IV. No practical attacks against the SHA-2 family exist as of 2026; SHA-256 is the default choice for new applications and is the hash function behind Bitcoin (for both mining and address derivation), TLS certificate fingerprints, Git's planned object-identity migration, the Ethereum transaction hash, JWT HS256 signatures, and most software-distribution checksums. SHA-512 is preferred when 256 bits of output isn't enough or when you want the slightly faster performance on 64-bit CPUs (SHA-512's internal operations are 64-bit, vs SHA-256's 32-bit, so it processes more data per CPU cycle on 64-bit hardware despite the larger output).

SHA-3 (Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche, won the NIST SHA-3 Competition in October 2012, standardised as FIPS 202 in August 2015) is the cryptographic insurance policy: structurally different from SHA-2 (sponge construction rather than Merkle-Damgård), so any breakthrough that broke SHA-2 wouldn't necessarily break SHA-3. SHA-3 isn't currently in this tool's algorithm list because the Web Crypto API didn't include it in the original spec, modern browsers may add it in future. The SHA-2 family is the recommended default for browser-side hashing today.

Modern Alternatives Beyond SHA-2

Two non-NIST hash families have gained traction for performance reasons. BLAKE2 (Aumasson, Neves, Wilcox-O'Hearn, Winnerlein, January 2013) is faster than SHA-2 with comparable security and is widely used in cryptocurrency, Argon2 password hashing, and high-performance applications where SHA-2's speed is a bottleneck. BLAKE3 (O'Connor, Aumasson, Neves, Wilcox-O'Hearn, January 2020) is a redesign that's parallelisable across many CPU cores and faster still, particularly attractive for hashing very large files because the work splits across cores cleanly. Neither is in the Web Crypto API standard, so this tool sticks with SHA-2 family + MD5 + SHA-1 for compatibility; for command-line BLAKE3 hashing the canonical implementation is the b3sum tool from the BLAKE3 reference repository. The choice for browser-side file hashing in 2026 remains SHA-256 unless there's a specific reason to use something else, broad compatibility, no patent issues, hardware-accelerated on most modern CPUs (Intel SHA Extensions since Goldmont 2016, ARMv8 SHA-2 instructions on essentially every smartphone), and acceptable speed even on multi-gigabyte files in the browser.

When File Hashes Earn Their Keep

• Verifying a downloaded file matches the publisher's checksum. Linux distributions (Ubuntu, Debian, Fedora, Arch), open-source projects (Node.js, Python, Go), and security-sensitive downloads (the Tor browser, signed firmware images) publish SHA-256 hashes alongside their downloads. After downloading, hash the file locally, compare to the published value character-by-character, if they match, the file arrived intact and isn't a tampered or interrupted copy.
• Finding duplicate files. Identical files always produce identical hashes regardless of filename, location, or modification timestamp. A simple deduplication workflow: hash every file in a directory tree, group by hash, anything with multiple files in the same group is a duplicate. Tools like fdupes on Linux do exactly this with MD5 (acceptable here because deduplication doesn't depend on cryptographic collision resistance).
• Detecting file modification. Hash a file today, store the hash, hash again later, compare, any difference means the file has changed even by one bit. Used by file-integrity-monitoring tools (Tripwire was the original, 1992; OSSEC and Wazuh are modern descendants), backup verification systems, and rsync-style incremental sync.
• Content-addressable storage. Git identifies every blob, tree and commit by its SHA-1 hash (migrating to SHA-256 in upcoming versions). IPFS uses multihash. Docker layers are addressed by their content hash. Any system where "this is the same content" needs to be answered cheaply and reliably uses content-hashing as the underlying mechanism.
• Digital forensics chain-of-custody. When evidence files are imaged, the forensic standard is to compute SHA-256 of the disk image at acquisition time and at every later point, any divergence proves tampering. NIST's National Software Reference Library (NSRL) publishes hashes of known good and known bad files for forensic triage.
• Software supply-chain verification. Sigstore, in-toto, SLSA, npm package integrity (integrity: sha512-... in package-lock.json), Go's module proxy checksum database, all rest on file hashing as the integrity primitive. The hash of a published artifact is the bridge between "I trust this signature" and "this is the artifact the signature attested to."

How This Tool Works

When you drop a file into the editor, the browser reads it into an ArrayBuffer via FileReader.readAsArrayBuffer() (or, in modern browsers, the more efficient File.arrayBuffer() Promise-returning method). The Web Crypto API's crypto.subtle.digest(algorithm, buffer) hashes the buffer with native code, implemented in C++ inside the browser engine, often using hardware acceleration (Intel SHA Extensions on x86-64 since Goldmont, ARMv8 SHA-2 instructions on essentially every smartphone). The returned ArrayBuffer is converted to a hex string for display. Three pure-JavaScript hashes (MD5 and SHA-1, where the Web Crypto API may decline or where a polyfill is in use) run via small dedicated implementations. No upload step, no server processing, no telemetry, verify in DevTools' Network tab while you drop a file (no requests fire), or take the page offline (airplane mode) after it loads and the hasher still works on local files. The practical file-size limit is browser memory: hashing a 1 GB file works but consumes ~1 GB of RAM during the operation; multi-gigabyte files may force the browser to swap or fail. For very large files, a dedicated command-line tool (shasum -a 256 on macOS/Linux, certutil -hashfile ... SHA256 on Windows) is the better choice.

Privacy: Why Browser-Only Matters Especially Here

Files you might want to hash include downloaded software (which you're verifying for integrity precisely because you don't trust it yet), private documents (whose hash you want to record without giving them to anyone), unreleased media files, evidence in a forensic investigation, or proprietary builds where even uploading the file to a hashing service is unacceptable. Server-side file hashers, even when they claim "we don't keep the file," receive the entire file content, by the time it's in their memory the privacy guarantee is gone. This tool runs entirely in your browser via the Web Crypto API; the file never traverses the network. Verify in DevTools' Network tab while you drop a file (the only network activity should be the initial page load). Take the page offline (airplane mode) after it loads (the hasher still works, proving the local-only architecture. For files containing anything sensitive) confidential documents, unreleased software, financial records, medical scans, anything covered by NDA or compliance regulation, browser-side hashing is the only safe option.

Frequently Asked Questions

Which hash algorithm should I use?

SHA-256 is the right default for any new use in 2026, broad compatibility, no known practical attacks, hardware-accelerated on every modern CPU. Use SHA-512 if you want a 512-bit output (slightly faster on 64-bit CPUs, more bits of collision resistance). Use MD5 or SHA-1 only when matching a published checksum that uses those algorithms (some Linux distributions still publish MD5 sums alongside SHA-256 for backward compatibility), never use either for any new cryptographic purpose. Match whatever algorithm the publisher of the file you're verifying chose.

Can you reverse a hash to get the original file?

No. Hash functions are deliberately one-way, given a hash, there is no efficient algorithm to recover the input. The only attack route is brute force: hash candidate inputs until one produces a matching hash. For files of any reasonable size (more than a few bytes) this is computationally infeasible, the number of possible files of even 1 KB exceeds the number of atoms in the observable universe many times over. This one-way property is what makes hashes useful for password storage (with salting and stretching), digital signatures, and content-addressable storage.

Is MD5 safe for file verification?

For non-adversarial integrity checks (catching accidental corruption from a flaky network or bad disk), MD5 is fine, random bit flips will produce a different MD5 with overwhelming probability. For adversarial verification (catching a malicious actor who substituted a file), MD5 is broken: collision attacks have been practical since 2004, and chosen-prefix collisions since 2008. Modern security practice: use SHA-256 for anything where someone might be trying to fool you, and MD5 only when the source is trusted and you just need a fast checksum.

Is there a file size limit?

No hard cap, but practical limits depend on browser memory. Files up to a few hundred MB hash quickly on any modern device. Files in the 1-2 GB range work but consume RAM equal to the file size during the hashing pass. Multi-gigabyte files may trigger swapping or browser OOM crashes. For very large files, command-line tools (shasum -a 256 file on macOS/Linux, certutil -hashfile file SHA256 on Windows, Get-FileHash in PowerShell) handle them better because they can stream the file rather than loading it all into memory.

What does it mean when two files have the same hash?

For a healthy hash function (SHA-256, SHA-512, or any in the SHA-2 family in 2026), it means the files are identical bit-for-bit, the probability of two distinct files producing the same hash is vanishingly small. For broken hash functions (MD5, SHA-1), it could mean either identical files or a deliberately constructed collision. The practical rule: if you compute SHA-256 of two files and get the same value, the files are the same. If you compute MD5 and get the same value, the files are probably the same but a determined adversary could have engineered them to collide.

Related Tools