Compute SHA-1, SHA-256, SHA-384 and SHA-512 hashes of text or a file, entirely on your device with the Web Crypto API — nothing is uploaded or stored. Runs entirely in your browser — your numbers never leave this device.
Hashes are computed on your device with the Web Crypto API; the file is read locally and never uploaded, and nothing you type or choose is stored. MD5 is not offered: it is not part of the Web Crypto API, and hand-rolled cryptography is a correctness risk — MD5 is also broken as a security hash, so modern tools should not encourage it.
| Algorithm | Digest size | Hex digits | Status |
|---|---|---|---|
| SHA-1 | 160 bits | 40 | Legacy — fine for checksums, broken for collision resistance |
| SHA-256 | 256 bits | 64 | Current workhorse — the safe default |
| SHA-384 | 384 bits | 96 | SHA-512 truncated to 384 bits |
| SHA-512 | 512 bits | 128 | Largest here — common for file fingerprints |
A cryptographic hash turns any input — a word, a password candidate, a two-gigabyte disk image — into a fixed-length fingerprint. This tool computes four of them at once (SHA-1, SHA-256, SHA-384 and SHA-512) using the Web Crypto API built into your browser: text is encoded as UTF-8 bytes, a chosen file is read as raw bytes, and the digests come back as lowercase hex. Change one bit of the input and roughly half the hex digits change; run the same input twice and the output is identical, which is what makes hashes useful for checksums, deduplication and integrity checks.
Two honesty points. First, privacy: hashes are computed on your device with the Web Crypto API; the file is read locally and never uploaded, and nothing is stored — important, because the files people hash are often exactly the ones they would not want on a stranger's server. Second, MD5 is deliberately missing: it is not part of the Web Crypto API, and hand-rolled cryptography is a correctness risk this tool will not take. MD5 is also collision-broken, so leaving it out is good riddance twice over. SHA-1 is included for compatibility and checksum work, but it is likewise no longer safe against deliberate collision attacks — for anything security-critical, SHA-256 or stronger is the floor.
What a hash is not: it is not encryption. There is no key and no way back — you cannot recover the input from the digest, only confirm that a candidate input produces it. That one-wayness is why comparing a downloaded file's SHA-256 against the publisher's printed digest proves the download is byte-for-byte what was published, without trusting the mirror that served it.
Two reasons. It is not part of the Web Crypto API — the browser's audited, native cryptography library — and implementing it by hand in page code would be hand-rolled crypto, a correctness risk for a tool whose whole job is producing exactly-right digests. MD5 is also broken: collisions can be constructed cheaply, so no new workflow should depend on it.
For checksums against accidental corruption, yes. For security — signatures, certificates, proving two files differ against an attacker — no: practical collision attacks against SHA-1 have existed since 2017. This page computes it because old systems and published checksums still use it, but SHA-256 is the minimum for anything adversarial.
No — a hash is a one-way function. The only way to 'reverse' one is to guess inputs and hash them until a digest matches, which is feasible only when the input space is small (a short password, a known filename). That is precisely why unsalted hashes of weak passwords leak them, and why this tool's digests of your text reveal nothing by themselves.
Switch to file mode, choose the download, and compare the SHA-256 (or whichever digest the publisher lists) character for character with the publisher's value — ideally from a different source than the download itself. Any difference, even one hex digit, means the bytes differ: a corrupted or tampered file.
No. Hashes are computed on your device with the Web Crypto API; the file is read locally and never uploaded, and the text you type is never stored. The digests exist only in your tab.
Usually an encoding difference: the other tool may hash the text as Latin-1 or UTF-16 bytes instead of UTF-8, or include a trailing newline you did not notice. For pure-ASCII text all byte encodings agree, which is why the hello example (2cf24dba…) reproduces everywhere; discrepancies appear with non-ASCII characters or hidden whitespace.
More in Developer Tools · Browse all tools