Loading Hash Generator…
Nothing entered yet. The digests below are of the empty input, which is a real and often useful value.
Collisions are public since 2017. Fine for a checksum or a Git object id, unfit for a signature.
The default choice. What TLS certificates, Bitcoin and most file checksums use.
SHA-512 truncated to 384 bits, with different initial values. Common in TLS cipher suites.
Works on 64-bit words, so it is often faster than SHA-256 on a 64-bit machine.
There is no MD5 here, deliberately. Web Crypto implements exactly four digests and MD5 is not one of them, because producing two files with the same MD5 has been a matter of seconds since 2004. Adding it would mean shipping a hand-written copy of a hash that must not be used for anything that depends on being hard to forge. SHA-1 is listed because Git object ids and older checksums still use it, with the same caveat: chosen-prefix collisions against it are published work, so it belongs nowhere near a signature.
A hash is not encryption and not a password store. It goes one way only, it cannot be reversed, and it also cannot be un-guessed: a digest of a short common string is looked up in a rainbow table instantly. Passwords need a slow, salted function such as Argon2id, scrypt or bcrypt, none of which is what this tool computes.
Type text or choose a file and the SHA-1, SHA-256, SHA-384 and SHA-512 digests appear together in lowercase hex. Computing all four rather than making you pick means a value can be compared against whichever length the other side publishes — 40 characters, 64, 96 or 128 — without guessing which algorithm made it. Paste a published checksum in and the tool reports a match and names the algorithm that produced it.
Text is converted to UTF-8 first, because a digest is taken over bytes, so the answer agrees with sha256sum and openssl dgst rather than with some other reading of the same characters.
The three letters abc hash under SHA-256 to ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, a published test vector, so any implementation disagreeing with it is broken. The empty input has a digest too, e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Add a full stop to a sentence and the digest is not nudged, it is replaced. Two 64-character strings with only a few coincidentally matching positions is the avalanche property working, and it is why a digest makes a good fingerprint: there is no near miss to interpret, only equal or not equal.
Length never varies with input. A single letter and a two-gigabyte disk image both leave SHA-256 as exactly 32 bytes, because the algorithm consumes fixed-size blocks into a fixed-size state.
Web Crypto, the browser API doing the work here, implements precisely these four. MD5 is not among them, which is a judgement rather than an oversight: producing two different inputs with the same MD5 has been practical since 2004, and a forged certificate built on exactly that was later found in the wild. Hand-writing one would mean shipping a broken tool for the sake of a complete menu.
SHA-1 is offered because real systems still use it — Git object names, older release checksums, some legacy protocols — but a collision was demonstrated in 2017 and a chosen-prefix collision in 2020, the variety that matters for forging a document. Treat it as an identifier, never a guarantee. SHA-384 and SHA-512 work on 64-bit words and are often faster on 64-bit hardware.
Comparing a file against the checksum on its download page is the common case, and a mismatch usually means a truncated transfer rather than anything sinister — re-fetching once is the right first move.
What the check proves is narrower than it looks. A checksum published beside the file only shows the two agree, and anyone able to replace the file could replace the number next to it. Protection against that is a signature verified against a key you already trust, which is why distributions publish a signed checksum file.
One trap catches everyone at least once: echo adds a trailing newline, so it hashes differently from the characters alone, and printf is what matches a digest taken here. Windows line endings do the same to a whole text file, turning every break into two bytes and every digest into a mismatch.
It is not encryption. There is no key and no way back, so a digest cannot be decrypted, only guessed at — and short or common inputs are found instantly in a lookup table, so hashing an email address or a six-digit code hides nothing.
Passwords therefore need a deliberately slow, salted function such as Argon2id, scrypt or bcrypt, and proving a message came from you needs a keyed construction such as HMAC. Neither is what this generator computes. Everything happens on your own machine: no text or file selected here is uploaded, inspected by a server, or kept afterwards.
SHA-256 unless something tells you otherwise: it is the default across TLS certificates, package managers and checksum files. A longer digest is not safer for identifying a file, it only doubles what you store and compare, so match whatever the other side publishes.
Usually a trailing newline, a partial download, or a different algorithm than you assumed. Compare the lengths first: 64 hex characters is SHA-256 and 40 is SHA-1, and those two can never agree.
Not by reversing it, because the process discards information — a fixed-size output cannot hold an arbitrary input. Predictable inputs can still be recovered by guessing, which is a different attack and a very effective one.
No. The browser reads the bytes locally and hands them to its own crypto engine, so the file never leaves the machine. The practical limit is your own memory rather than an upload size cap.