Hash Generator
Generate cryptographic hashes using the browser’s Web Crypto API. Your input never leaves the page.
Runs entirely in your browser. Your input is never sent to our servers.
What is Hash?
A hash generator produces a fixed-length digest from input of any size using a cryptographic hash function, so that the same input always yields the same digest and any change to the input produces an entirely different one.
What this Hash Generator does
Enter text and this tool computes its SHA-1, SHA-256, SHA-384 and SHA-512 digests at once, using the browser’s own Web Crypto implementation. Nothing is sent anywhere.
Showing all four together makes the shape of the family visible: the same input, four digest lengths, no relationship between the outputs. It also makes the length differences concrete when you are choosing a column width or comparing against a stored value.
How to use it
- Type or paste the text to hash. Input is treated as UTF-8.
- Read the digest you need and copy it.
- Switch to uppercase if you are comparing against a value that was recorded that way — hex digests are case-insensitive but string comparison is not.
Understanding your results
Digest length is fixed by the algorithm, never by the input. SHA-256 always returns 64 hex characters whether you hash one letter or a gigabyte.
A one-character change rewrites the whole digest. There is no partial similarity to read; two digests either match or they do not.
Encoding matters. The digest is of the UTF-8 bytes. Hashing the same characters in a different encoding produces a different result, which is a common reason two systems disagree about a checksum.
Why this matters
Hashes underpin integrity checks, content addressing, digital signatures and certificate fingerprints. In each case the guarantee is the same: finding a second input with the same digest must be computationally infeasible.
When that guarantee breaks, everything built on it breaks quietly. SHA-1 collisions were demonstrated in practice in 2017, and chosen-prefix collisions followed in 2020 — which is why certificate authorities and version control systems moved away from it.
Common mistakes
Hashing passwords with these functions. They are designed to be fast, which is exactly wrong for password storage. Use Argon2id, scrypt or bcrypt, which are deliberately slow and memory-hard.
Adding a salt and assuming that fixes it. A salt stops precomputed rainbow tables; it does nothing about the raw guessing rate, which is the actual problem with a fast hash.
Comparing digests with a plain string equality in security-sensitive code. Use a constant-time comparison so response timing cannot leak how much of the value matched.
Choosing SHA-512 for strength. SHA-256 is not the weaker option; SHA-512 is simply faster on 64-bit hardware. Both are unbroken.
Limitations
No MD5. The Web Crypto API does not implement it, and that is the right default — MD5 has been broken for collisions since 2004 and offering it here would invite its use.
Text only. Hashing a file requires reading its bytes exactly as stored; copying a file’s contents into a text box will change line endings or encoding and produce a different digest.
SHA-1 is included solely so you can read digests that already exist. It should not be chosen for anything new.
Frequently asked questions
Why is there no MD5 option?
The browser Web Crypto API does not provide MD5, and its collision resistance has been broken since 2004. Including it would encourage use in new work where it does not belong.
Can a hash be reversed?
Not by computation. But a hash is deterministic, so an attacker can guess inputs and compare digests. For low-entropy inputs such as passwords that is fast, which is why password storage needs a slow function rather than a fast one.
Is SHA-256 or SHA-512 more secure?
Neither is broken. SHA-512 produces a longer digest and is usually faster on 64-bit processors; SHA-256 is the common default and is entirely adequate for integrity and fingerprinting.
Why do two tools give different digests for the same text?
Almost always encoding or trailing whitespace. The digest covers the exact bytes, so a trailing newline or a different character encoding changes the result completely.
References
Last reviewed