MD5, SHA-1, SHA-2 and CRC digests of text or a file, with HMAC and verification against a published digest
Initializing in your browser…
Hash files with MD5, SHA-1, SHA-2 and CRC, and verify them against a published digest or a whole checksum file
Build a colour harmony that holds its lightness by rotating hue in OKLCH, with the contrast of every pair, a perceptually even tint and shade ramp, and what a colour blind reader sees
Generate QR codes and check each one scans by decoding it back before you download it
You downloaded a file and the project published a SHA-256 line to check it against.
Input
text "abc", or the downloaded file
Digests
MD5 900150983cd24fb0d6963f7d28e17f72 Broken for collisions SHA-1 a9993e364706816aba3e25717850c26c9cd0d89d Broken for collisions SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad Recommended CRC-32 352441c2 Not cryptographic
Every ticked algorithm computes over the same input at once and each digest carries a label saying what it is still safe for. Paste the published line into Verify and the tool works out the algorithm from the digest length and compares in constant time, accepting bare hex, base64, colon-separated hex or a whole sha256sum line with its filename. CRC-32 and MD5 stream a file a chunk at a time, so file size is not a limit for them.
A cryptographic hash function maps arbitrary-length input to a fixed-length output, the digest, in a way that is fast to compute forward and infeasible to reverse. The standard algorithms have different output sizes: MD5 produces 128 bits (32 hex characters), SHA-1 produces 160, SHA-256 produces 256, SHA-384 produces 384 and SHA-512 produces 512. Size is not the same thing as security. MD5 is 128 bits and was broken for collisions in 2008; BLAKE2b truncated to the same width remains secure. Two properties matter, for different jobs. Preimage resistance means that given a digest you cannot find any input that produces it, which is what protects a hashed value from being read back. Collision resistance means you cannot find two different inputs with the same digest, which is what protects an integrity check, because it stops an attacker crafting a malicious file that matches a published hash. MD5 is broken for collisions but not for preimages, which is why it survives as a non-adversarial checksum. SHA-1 fell to the 2017 SHAttered attack, which produced two PDFs with the same SHA-1. SHA-256 and above are unbroken for both. This tool labels each algorithm with which of those it is, next to every digest it produces, so the choice is made in front of you rather than behind you.
The tool computes every algorithm you tick at the same time, over the same input, and updates as you type. Text is encoded as UTF-8 before hashing, which is what every other tool and library will have done, so an accented word or a CJK string or an emoji gives the digest you would get from `sha256sum` on a UTF-8 file with the same content. The empty string has a digest of its own and the tool shows it: SHA-256 of nothing is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is a useful thing to recognise when a pipeline hands you an empty file.
Seven cryptographic algorithms are offered: MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA-512/256 and SHA-512/224. Web Crypto covers the four SHA-1 and SHA-2 primitives natively; MD5 and the truncated SHA-512 variants come from node-forge, which the page already carries. Four non-cryptographic checksums are offered alongside them: CRC-32 (the ISO-HDLC one that zip, gzip and PNG use), CRC-32C (the Castagnoli polynomial behind iSCSI, ext4 and Btrfs), Adler-32 (the zlib stream checksum) and CRC-16/ARC. Each is implemented from its published parameters and each agrees with its published check value, the digest of the ASCII string 123456789: CBF43926 for CRC-32, E3069283 for CRC-32C, BB3D for CRC-16/ARC and 091E01DE for Adler-32.
Files are hashed in the page too, by drop or by picker. The CRC family and MD5 run as true streams, a chunk at a time, so a file of any size works with only one chunk in memory. The SHA algorithms have no incremental interface in the browser, so when one of them is selected the file is buffered for the length of the run, and the tool says so on screen rather than leaving you to find out.
HMAC is a keyed construction, not a hash of the key concatenated with the message, and the difference matters: the most common reason an HMAC does not match a server is that the secret was published as hex or base64 and got hashed as its own characters instead of the bytes it stands for. The key field therefore has an encoding selector, and a key given as hex or base64 is decoded before use. An empty key is legal per RFC 2104 and works here. The output matches RFC 4231 test vectors and the openssl binary.
Verify mode takes a digest someone published and tells you whether the text or file in front of you produces it. It accepts a bare hex string, hex with spaces or colons, base64, or a whole line of `sha256sum` output including the filename, works out which algorithm could have produced a digest of that length, and compares in constant time so the answer cannot be extracted a byte at a time by timing.
For password storage, none of this is the right tool. SHA-256 runs billions of times a second on a GPU, so a stolen database of SHA-256 password hashes falls quickly. Use bcrypt, scrypt or Argon2, which are deliberately slow and have a tunable cost. Everything here happens in your browser: the text and the file never leave the page, and the shareable link carries only the algorithm and format, never what you hashed.
Drop the file in, paste the whole line the project published, and read match or no match. The algorithm is worked out from the digest length.
Reproduce an HMAC-SHA256 signature with the secret given as hex or base64 rather than as text, which is where most signature mismatches come from.
Get a stable SHA-256 for a string or a file to use as a cache key or an object id.
Produce the CRC-32 a zip or PNG would carry, or an MD5 an older system still expects, with both clearly labelled as non-adversarial.
SHA-256 unless something else demands otherwise. MD5 and SHA-1 are broken for collisions and are here for compatibility with systems that still use them; the tool labels them as such next to every digest. The CRC family is for spotting accidental corruption and is trivially forged, so it is never an integrity check against an attacker.
Yes, by dropping it on the input box or using the file button. CRC-32, CRC-32C, Adler-32, CRC-16 and MD5 stream a chunk at a time, so file size is not a limit for those. The SHA algorithms have no incremental interface in the browser, so selecting one buffers the file for the length of the run.
Usually because the secret was published as hex or base64 and got hashed as its own characters. If your key is 64 hex characters, it is 32 bytes, not 64. Set the key encoding to hex and the digest will change.
No. Hashing runs in your browser through the Web Crypto API and, for MD5, a JavaScript implementation on the page. The text and the file never leave the tab, and the shareable link carries only the algorithm and the output format.
Not for storage. A general-purpose hash is designed to be fast, which is the opposite of what password storage needs. Use bcrypt, scrypt or Argon2, which have a tunable cost and take a hundred milliseconds or more per hash on purpose.
A real value, and the tool shows it. SHA-256 of the empty string is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 and MD5 is d41d8cd98f00b204e9800998ecf8427e. Recognising them saves time when a pipeline has handed you an empty file.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.