Compute SHA-256, SHA-384 and SHA-512 digests of text or of a local file, then copy a digest or export all of them. Everything is calculated by your browser using the Web Crypto API — your text and your files are never uploaded, stored or sent anywhere. Hashing is one-way and is not encryption.
Up to 1.00 MB of UTF-8 text. Hashes update as you type.
Type something to see its hashes.
SHA-256, SHA-384, SHA-512 and a legacy SHA-1 are all computed at once.
Hashes are computed locally with crypto.subtle.digest and output as lowercase hex of the full digest — never shortened or reformatted. The exports contain the digests only; your text is not written into them.
Paste an expected hash next to the one you have. Case does not matter, and a whole sha256sum line is accepted — the first token is used. The length of the expected hash decides which digest it is being checked against.
Hashing happens locally in your browser. Your text and files are not uploaded, not stored and not sent anywhere, and no history of what you hashed is kept. A digest proves the input has not changed — it does not hide it, and it cannot be reversed, so it is not encryption. Browse all tools.
Generate SHA-256, SHA-384, SHA-512 and SHA-1 hashes of a piece of text or a local file, all at once, and check a hash you were given against the digest of a file you have. Everything is computed by the browser's own crypto implementation on this device.
Rather than picking an algorithm first, the tool shows every supported digest side by side for the same input. That is what makes it useful for verifying a download: a site publishes one hash, and you can see immediately whether the value in front of you matches it without having to guess which algorithm it used.
A hash is a one-way fingerprint of the input. It cannot be reversed into the original text, and no key turns it back — the only thing you can do is hash a candidate and see whether it produces the same value. That is exactly how password storage works, and also why a short or common password can still be cracked: an attacker hashes guesses and compares.
SHA-1 is still the right tool for checking an old checksum or reproducing a git object id, so it is here rather than quietly omitted. It is also broken for security purposes — collisions have been demonstrated in practice — so it is labelled legacy and listed last, instead of being presented as an equal choice to the three SHA-2 digests above it.
Hashing a file means reading its bytes, and the page reads them locally through the File API. Nothing is uploaded, and the digest is produced by `crypto.subtle.digest`, which is the browser's own implementation rather than a JavaScript rewrite.
No file and no text leaves this device. Both modes run through the browser's own crypto implementation, and the page makes no request — which matters most for the file mode, where the alternative would mean uploading a document to someone else's server just to fingerprint it.
No. Hashing throws information away on purpose, and there is no key that undoes it. What people do instead is hash a guess and compare the result: if the input matches, the hashes match. That is why the strength of a hashed password depends entirely on how hard the original password is to guess.
SHA-256 unless something specific says otherwise. It is the common default, it is not broken, and nearly every system publishes checksums in it. Use SHA-384 or SHA-512 if you want a longer digest, and reach for SHA-1 only to match a value that some existing system already produced — not as a new choice.
Almost always because the inputs differ in a way you cannot see. A trailing newline, a Windows line ending against a Unix one, non-ASCII text read with a different character encoding, or a file opened in text mode all change the bytes and therefore the hash. Hashes are exact: one byte different is a completely different digest.
