Hash Generator
Compute MD5, SHA-1, SHA-256, SHA-512 and CRC-32 over identical UTF-8 bytes, with an optional salt and HMAC signature mode.
Hash Generator workspace
Source Editor
Press Ctrl/Cmd + Enter to run.
Your draft is kept in this tab only (sessionStorage) and disappears when the tab closes. .
Result Console
Using Hash Generator
Type or paste the text you want to fingerprint into the editor.
Add a salt if you are reproducing an existing scheme, or tick HMAC signature mode and enter the secret key.
Press Hash Input to fill the digest table with every algorithm at once.
To fingerprint a file instead, use the file picker, which computes SHA-256 and SHA-512 in this tab.
Five digests are computed from one input so you can compare a published checksum against what you actually hold. MD5 and CRC-32 run in JavaScript, the SHA family runs through Web Crypto, and all of them read the same UTF-8 byte sequence — which is what makes the columns comparable.
Type or paste text and five digests appear at once: MD5, SHA-1, SHA-256, SHA-512 and CRC-32. All five read the same UTF-8 bytes, so the values you see side by side are describing the same input.
Read this before you hash a password
A bare digest is the wrong tool for storing a password, and the reason is speed. SHA-256 is designed to be fast; a commodity GPU will compute it billions of times a second. That is a virtue when you are checksumming a disk image and a catastrophe when your database of hashed passwords leaks, because the attacker simply hashes a wordlist and compares.
Password storage needs a function that is deliberately slow and memory-hungry, with a per-user salt and a tunable work factor: bcrypt, scrypt, or Argon2id. Every mainstream language has a library. Nothing on this page substitutes for one, adding a salt in the field below included.
What these digests are genuinely good at: verifying that a downloaded file matches the checksum its publisher posted, generating a cache key from the contents of an object, spotting duplicate files, and building an ETag. Those are the jobs to bring here.
What each algorithm is worth
MD5 produces 128 bits and is thoroughly broken for anything adversarial. Two different inputs colliding on purpose is a laptop-minutes exercise, so it must never gate a signature or an integrity claim. It remains fine as a non-adversarial fingerprint — deduplicating your own files, keying a cache — and it is still what many vendors publish next to a download.
SHA-1 is 160 bits and was broken in practice in 2017 by the SHAttered collision. Git still uses it internally; new designs should not.
SHA-256 and SHA-512 are the current defaults and have no practical attacks against them. On a 64-bit machine SHA-512 is often the faster of the two despite the longer output.
CRC-32 is not a cryptographic hash at all. It is a 32-bit error-detecting code from the world of Ethernet frames and ZIP archives, trivially forced to any value you like, and useful only for catching accidental corruption. If you are checking this implementation against another, crc32("a") is e8b7be43 and crc32("123456789") is cbf43926 — the standard test vectors.
Salt and HMAC do different jobs
The Salt field appends its text to your input before hashing. It is there for reproducing a scheme you already have, or for demonstrating how a single extra character changes every bit of the output. It does not turn a fast hash into a password function.
HMAC signature mode is a different construction entirely — it takes a secret key and mixes it into the digest twice, in the manner RFC 2104 specifies, and produces a value nobody without the key can forge. That is what you want for signing a webhook payload or verifying one that arrived. Tick the box, supply the key, and you get HMAC-SHA-256 and HMAC-SHA-512. The unkeyed columns are marked N/A in this mode, because they do not apply.
Hashing a local file
The file picker computes SHA-256 and SHA-512 over the file's bytes. Only those two, because the browser's Web Crypto interface implements SHA-1, SHA-256, SHA-384 and SHA-512 and nothing else — MD5 has never been part of it, and CRC-32 was never going to be. Those two columns show N/A for file input and this page will not pretend otherwise. For an MD5 checksum on a large file, md5sum or certutil -hashfile on your own machine is the answer.
Text input is hashed in JavaScript for MD5 and CRC-32 and through Web Crypto for the SHA family, all over the identical byte sequence. Before the rebuild, MD5 hashed something else entirely for any non-ASCII input, so two columns on one screen described two different documents.
Nothing is uploaded. File bytes are read with FileReader and never leave the tab, and text you paste is held in sessionStorage only until this tab closes.
Frequently asked
Can I use these digests to store passwords?
No, and adding the salt field does not change that. These functions are built to be fast, and a commodity GPU computes billions of them per second, so a leaked table falls to a wordlist quickly. Password storage needs a deliberately slow, memory-hard function with a tunable work factor: bcrypt, scrypt or Argon2id.
Why does hashing a file only show SHA-256 and SHA-512?
The browser's Web Crypto interface implements SHA-1, SHA-256, SHA-384 and SHA-512 and nothing else. MD5 has never been part of it and CRC-32 is not a cryptographic hash at all, so those columns show N/A for file input rather than a made-up value. Use md5sum or certutil locally if you need an MD5 checksum of a file.
How is HMAC mode different from adding a salt?
A salt is simply extra text appended before hashing, useful for reproducing an existing scheme. HMAC mixes a secret key into the digest twice using the construction from RFC 2104, producing a value nobody without the key can forge — which is what you need to sign or verify a webhook payload.
Do all five algorithms hash the same input bytes?
They do now. Before the rebuild, MD5 read something other than the UTF-8 bytes for any non-ASCII input and CRC-32 was wrong for roughly half of all inputs including plain ASCII, so two columns on one screen could describe two different documents.