What a hash is, and what it isn't
A cryptographic hash function takes any input — text, a file, anything — and produces a fixed-length string (the "hash" or "digest") that's effectively unique to that exact input. Change even a single character, and the entire hash changes unpredictably (the "avalanche effect"); there's no way to shrink the input a little at a time and see the hash shift correspondingly. This makes hashes useful for two related but distinct purposes: integrity verification (confirming a downloaded file matches what the publisher intended, byte for byte) and, for some algorithms, security applications like storing a password's hash instead of the password itself. A hash is not encryption — it's one-way. There's no "un-hashing" a value back to its original input.
Algorithm comparison
All five algorithms this tool computes, side by side:
| Algorithm | Digest length | Status |
|---|---|---|
| MD5 | 128 bits | Legacy |
| SHA-1 | 160 bits | Legacy |
| SHA-256 | 256 bits | Recommended |
| SHA-384 | 384 bits | Recommended |
| SHA-512 | 512 bits | Recommended |
SHA-256 hash generator
SHA-256 is part of the SHA-2 family and produces a 256-bit (64 hex character) digest. It's the algorithm most commonly recommended today for general-purpose integrity and security use: it's what secures Bitcoin's proof-of-work, and it's the algorithm Git is migrating to as its next commit-hashing algorithm, replacing SHA-1. No practical collision attack against SHA-256 is currently known. If you're not sure which algorithm to use for a new integrity check, SHA-256 is a strong default for general-purpose integrity checks and is widely supported.
SHA-512 hash generator
Also part of the SHA-2 family, SHA-512 produces a larger, 512-bit (128 hex character) digest — a bigger security margin than SHA-256, at the cost of a longer output. SHA-512 operates natively on 64-bit words, while SHA-256 operates on 32-bit words (see FIPS 180-4 in Sources, below, for the structural specification) — so SHA-512 can be faster than SHA-256 in some 64-bit implementations, even though it produces twice the output. It shows up in practice more than its lower profile suggests: npm's own documentation confirms it uses SHA-512 (not SHA-256) for the package-integrity hashes recorded in every package-lock.json.
SHA-384 hash generator
SHA-384 produces a 384-bit (96 hex character) digest. Structurally, it's SHA-512 run with different initial values and its output truncated — the same 64-bit-word internal design as SHA-512, just a shorter final digest; actual performance depends on the implementation and hardware. It's a reasonable middle ground when you want SHA-512's internal design but don't need (or don't want to store) a full 128-character digest.
SHA-1 hash generator
SHA-1 produces a 160-bit (40 hex character) digest. It predates the SHA-2 family and is cryptographically broken: on 23 February 2017, researchers at CWI Amsterdam and Google publicly demonstrated the first real-world SHA-1 collision — two different files with the same SHA-1 hash — confirming in practice what had been considered likely for years. It should not be used anywhere security depends on hashes being hard to forge. Git has historically used SHA-1 for object IDs, and provides a transition path to SHA-256 for exactly this reason.
MD5 hash generator
MD5 produces a 128-bit (32 hex character) digest. It's the oldest legacy algorithm this tool offers and was designed for fast digest computation — but, like SHA-1 above, it's cryptographically broken for security purposes. Practical collision attacks against MD5 have existed since 2004-2005, meaning an attacker can deliberately construct two different inputs that produce the same MD5 hash. Neither MD5 nor SHA-1 should be used anywhere security depends on hashes being hard to forge — password storage, digital signatures, certificate validation.
Both are still included, and still genuinely useful, for non-adversarial integrity checks where nobody is deliberately trying to produce a matching hash: verifying a download wasn't corrupted in transit, or matching a file against a checksum a tool or vendor published in MD5 or SHA-1 (still common for legacy software and some package registries). For anything where a malicious actor might deliberately try to produce a matching hash, use SHA-256 or stronger instead.
File checksum calculator: verify a file's checksum
Switch to File mode above and select a file to use this as a file checksum calculator — every hash is computed locally from the file's actual bytes, nothing is uploaded. To verify a file checksum against a value a publisher provided (often in a .sha256, .md5, or CHECKSUMS file, or listed directly on the download page), paste that published value into the "Compare with an expected hash" field. It's checked against all five computed hashes at once, case-insensitively, and understands common checksum-file formats directly — a raw hex digest, a sha256sum-style line (<hex> filename), or a BSD-style line (SHA256 (filename) = <hex>) — so you can paste the line exactly as published without editing it down to just the hex first. Published SHA-256 checksums are common, reflecting the "Recommended" status in the comparison table above.
Frequently asked questions
Is a hash the same as encryption?
No. Encryption is reversible with the right key; hashing is one-way by design — there's no key that turns a hash back into its original input. Hashing verifies that data matches a known value; encryption keeps data confidential from anyone without the key.
Can I hash a password here to store it in my application?
Not safely with these general-purpose hash functions on their own. Password storage needs a hash function specifically designed to be slow and to incorporate a random "salt" per password — bcrypt, scrypt, or Argon2, not a single pass of SHA-256. General-purpose hashes like the ones here are deliberately fast, which is exactly the wrong property for password storage: it's what lets an attacker with a stolen password database try billions of guesses per second.
Why do two different files sometimes appear to have "similar" hashes?
They don't, genuinely — any apparent similarity is coincidental. A well-designed hash function's output has no relationship to its input's structure; two inputs differing by one byte should produce hashes that look statistically unrelated. If you're comparing hashes and they look partially similar, that's not a partial match of any kind — only an exact, complete match means anything.
Does this tool upload my file anywhere?
No — file hashing uses the browser's own File and ArrayBuffer APIs entirely locally; the file's contents are read directly into memory and hashed there, never included in any network request this tool makes. Nothing is saved in browser storage either, and third-party analytics tracking is disabled on this page specifically.
Sources
- RFC 1321 — The MD5 Message-Digest Algorithm
- FIPS 180-4 — Secure Hash Standard (SHA-1, SHA-256, SHA-384, SHA-512)
- RFC 6151 — Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (IETF, co-authored with NIST; cites the original Wang & Yu 2004/2005 MD5 collision research)
- SHAttered — the first public SHA-1 collision (CWI Amsterdam & Google, 23 February 2017)
- Git — hash function transition (Git's own documentation on moving from SHA-1 to SHA-256)
- npm Docs — package-lock.json (confirms the SHA-512 integrity field)
Last reviewed: . MD5 is computed with a from-scratch implementation of RFC 1321, verified against its own official test vectors; SHA-1/256/384/512 use the browser's native Web Crypto API.