SHA Hash Generator
Hash text with SHA-1, SHA-256, SHA-384 and SHA-512 as you type. Your browser does the work, so the text never leaves the page.
43 characters, 43 bytes of UTF-8 going in.
Nothing you type is uploaded. Your own browser computes the digests, and the text never reaches a server.
Why there is no MD5
MD5 is not on this page because the browser does not have it. The Web Crypto digest call takes SHA-1, SHA-256, SHA-384 and SHA-512, and that list is the whole of it — MD5 would have to be our own code shipped to you, and it is not a hash worth adding weight for.
Before you reach for SHA-1
SHA-1 is here because file checksums and older systems still quote it. Do not reach for it when the answer has to resist an attacker: the browser documentation calls it vulnerable and says it should not be used for cryptographic applications.
waiting for the browser
waiting for the browser
waiting for the browser
waiting for the browser
A hash turns any amount of text into a fixed number of bits that changes completely if you alter so much as one character, and cannot be run backwards to recover what went in. That makes it useful for checking that a file arrived intact, for comparing two things without storing either, and for signing a request. This page computes the four digests your browser itself can produce, all at once and as you type. The text is hashed on your machine; nothing is uploaded, which matters more here than on most pages, because the thing people most often want hashed is the thing they least want to send.
How it is calculated
digest = SHA-n(UTF-8 bytes of the text), written as lowercase hexadecimal
The text is first turned into UTF-8 bytes, so what is hashed is the encoded form and not the characters as you see them. Those bytes are padded to a whole number of blocks — 512 bits for SHA-1 and SHA-256, 1024 for SHA-384 and SHA-512 — with the original length written into the final block. Each block is then folded into a running state through eighty or sixty-four rounds. The constants that drive those rounds are not arbitrary: the standard defines them as the leading fractional bits of the cube and square roots of the first prime numbers, which is how it demonstrates that nothing was chosen up anyone's sleeve.
Questions people ask
- Where is MD5?
- It is not here because the browser does not have it. The Web Crypto digest call takes SHA-1, SHA-256, SHA-384 and SHA-512, and that list is the whole of it. Offering MD5 would mean shipping our own implementation of it to you, and MD5 is not a hash worth downloading extra code for. RFC 6151 settled that in 2011: MD5 is no longer acceptable where collision resistance is required, and the collision attacks against it were successfully applied to X.509 certificates. If you need MD5 to check an old download, the md5sum or certutil command on your own machine already does it.
- Should I still use SHA-1?
- For file checksums and for older systems that quote it, yes, and that is why it is on this page. For anything an attacker has an interest in forging, no. The browser documentation is blunt about it: SHA-1 is considered vulnerable and should not be used for cryptographic applications. SHA-256 is the sensible default when you get to choose.
- Is SHA-384 just SHA-512 cut short?
- Almost, and the difference matters. It runs exactly the same computation over 1024-bit blocks, then keeps the first 384 bits — but it starts from a different initial hash value, taken from the square roots of the ninth through sixteenth primes rather than the first eight. Truncating a SHA-512 digest yourself would give a different answer, and would leave the discarded half recoverable in ways SHA-384 does not.
- Can I hash a password with this?
- You can, but you should not store the result. A plain SHA digest is built to be fast, and fast is exactly wrong for a password: hardware will try billions of guesses a second against it. Password storage wants a function designed to be slow and salted per user, such as bcrypt, scrypt or Argon2. Use this page to understand what a digest is, not to build a login.
- Why does the same text give a different digest somewhere else?
- Almost always because the bytes differ, not the algorithm. A trailing newline, a byte order mark, CRLF line endings instead of LF, or a different text encoding all change the input completely. This page hashes exactly the characters in the box, encoded as UTF-8, with nothing added — so a file checksum will only match if the file has no trailing newline either.
- Does the page work without a secure connection?
- The browser exposes this feature only in a secure context, which in practice means HTTPS or localhost. Opened over plain HTTP the digest interface simply is not there, and the page will say so rather than showing you an empty box.
Related tools
JSON Formatter and Validator
Indent, minify and check JSON as you type. When it will not parse, this page names the line and column where the text stops making sense.
Base64 Encode and Decode
Turn text into Base64 and back as you type, in the standard alphabet or the URL-safe one. Nothing you paste leaves the page.
Password Generator
Generate a random password in your browser, with a length range taken from the NIST digital identity guidelines. Nothing is transmitted and nothing is stored.
Found a problem, or want more?
A number that disagrees with its source is a defect, not a rounding preference.
What did you enter, what did the tool show, and what did you expect instead? If you have a source that disagrees with ours, a link to it is the most useful thing you can send.
Opens your mail app with the page and tool already filled in.