Type or paste text, or choose a file, and every hash is computed at once: MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, Keccak-256 (the original Keccak padding that Ethereum uses) and CRC-32. Tick HMAC to compute keyed hashes instead, with a text or hex key. Results can be shown in hexadecimal (lower or upper case), Base64 or Base64url, and the compare box tells you which algorithm, if any, produced a hash you paste. Text and files never leave your browser; files are read in slices, so large ones work too.
Text is hashed as UTF-8 bytes
A hash is computed over bytes, not characters. The tool encodes text as UTF-8, exactly as typed, which is what printf '%s' 'text' | sha256sum does on a command line. Two things commonly make a hash "not match":
- A trailing line break.
echo 'text' | sha256sum hashes the text plus a newline, so the result differs. Use printf '%s' or echo -n. - A different encoding. "é" is two bytes in UTF-8 (C3 A9) and one in Latin-1 (E9). The byte count under the text box shows what is being hashed.
Worked example: the text The quick brown fox jumps over the lazy dog (43 bytes) has MD5 9e107d9d372bb6826bd81d3542a419d6, SHA-256 d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592 and CRC-32 414fa339. With HMAC and the key key, HMAC-SHA256 is f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8.
Which algorithm for what
- SHA-256 is the sensible default for checksums, content addressing and signatures. SHA-512 is as strong and often faster on 64-bit CPUs; SHA-384 is SHA-512 cut short.
- SHA-3 (SHA3-256, SHA3-512) is a different design from SHA-2, standardised in FIPS 202. Use it when a protocol asks for it. Keccak-256 is not the same as SHA3-256: it uses the padding from before standardisation, and appears in Ethereum.
- MD5 and SHA-1 are broken for collisions: people can make two different inputs with the same hash. They are still fine for detecting accidental corruption, and some old systems expect them, but never use them where someone could craft an input.
- CRC-32 is a checksum, not a cryptographic hash: it catches transmission errors (ZIP, PNG and gzip use it) but is trivial to forge.
- HMAC proves a message came from someone who knows the key, as webhook signatures do. Comparing
SHA-256(key + message) instead is vulnerable to length-extension attacks; HMAC is not. - Passwords: none of these. A fast hash lets an attacker try billions of guesses a second. Use a password hashing function such as Argon2id, scrypt or bcrypt.
The article which hash to use: MD5, SHA-256 or HMAC explains these choices with examples.
MD5 is tested with the full RFC 1321 suite, SHA-1 and SHA-2 with the FIPS 180-4 examples, SHA-3 with the NIST values (including one million times "a"), CRC-32 with the standard check value (CBF43926 for "123456789"), and HMAC with the RFC 2202 and RFC 4231 test cases; all of them are also compared with OpenSSL. For checking a download against a published checksum, the file hash checker has a dedicated layout. To encrypt rather than hash, use text encryption.
