Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384, SHA-512 and HMAC, then compare a checksum, all in your browser.
This hash generator computes MD5, SHA-1, SHA-256, SHA-384, SHA-512 and HMAC for any text or small file, right in your browser, so the bytes never leave the page. Paste a string or drop a file, paste an expected digest to compare against, switch the output between hex and Base64, and sign a message with an HMAC secret when you need to prove it came from a holder of the shared key. MD5 and SHA-1 are kept on hand, clearly tagged legacy, for the old checksums you still have to verify, while SHA-256 stays the sane default for anything modern. The notes flag which outputs are safe and which should stay nowhere near a real security decision, because a hash is a fingerprint, not encryption, and passwords belong in a slow KDF like Argon2, bcrypt or scrypt instead.
100% in your browser. Nothing you type ever leaves this page.
Local hash, checksum, MD5 legacy and HMAC workbench
I built this out of spite, honestly. Every time a download's checksum didn't match, I'd go hunting for a hash page I actually trusted, and half of them ship your text off to some server. So. Paste text or drop a small file. You get MD5, SHA-1, SHA-256, SHA-384 and SHA-512, computed right here in your browser. Paste an expected digest to compare against. Flip between hex and Base64. Sign something with HMAC. And the part people get wrong, when a hash is the right call versus when you really wanted a signature or a proper password hash, that's down below.
It all runs locally, so your text, your file, your secret, none of it leaves the page. And I'll say it as often as it takes: don't store passwords as plain MD5 or a raw SHA digest. Wrong tool for the job.
Hash generators are for fingerprints, not secrecy
The way I think about it: a hash is a fingerprint. Same bytes in, same digest out, every single time. Change one character and the whole string scrambles into something unrecognizable. Great for checksums on a release download, cache keys, hunting duplicates, a sample payload in your docs, that kind of quick integrity check. Encryption it is not. No decrypt button. No key that walks it back. A bare hash sitting on its own won't protect a password or a bearer token, and I think people forget that more often than they'd admit.
I built this around the stuff I actually touch in a normal week. MD5's in here for when some ancient checksum lands on your desk. SHA-1 for the systems that still won't let go of it. SHA-256, SHA-384 and SHA-512 cover everything modern. Type something in or drop a small file, paste a checksum to compare, pick hex or Base64, sign with an HMAC secret. The notes flag which outputs are safe to paste into a doc, and which ones should stay nowhere near a real security decision.
How to choose an algorithm
Left to my own devices, I grab SHA-256 nearly every time. It's quick, nobody picks a fight over it, and the digest lands at a reasonable length. SHA-512 only comes out when the project already talks in it, or when nobody minds the longer string. MD5? One reason, ever. Some old tool handed me an MD5 and I have to verify it. Its collision resistance has been dead for years now, so it stays miles from any fresh security call. HMAC is a different animal: reach for it when the other side needs proof the message came from someone holding the shared secret, not just proof the bytes made it across intact.
- MD5 is here for old checksums and migration grunt work. Keep it away from anything security-related.
- SHA-1 is past its prime too, but older systems still hand it to you, so you'll meet it.
- SHA-256 is my default for anything modern.
- HMAC ties a message to a secret. That's the thing you want behind signed webhooks or a quick API example.
- File hashing earns its keep the moment you're verifying a downloaded archive, or an export you generated five minutes ago.
Common hash debugging examples
A vendor ships a checksum next to the download? Hash the file, check it lines up, then run it. Never the other way round. An API signs its webhooks? Hash the raw body byte-for-byte, not the pretty-printed JSON your HTTP client politely reformatted for you. People trip on that one constantly. And when two payloads look identical but the digests refuse to agree, it's whitespace nine times out of ten. Or encoding. A stray CRLF, fields shuffled into a different order. I lost most of an afternoon once to a single trailing newline, which still annoys me. Passwords, though? None of this. Go grab Argon2, bcrypt or scrypt and leave the fast SHA digests out of it entirely.
Frequently asked questions
Is hashing the same as encryption?
Nope. And the gap between them trips a lot of people up. Encryption is a round trip: hold the key, get your original back. Hashing only goes one direction, like a fingerprint you can't un-press. Here's the catch though. If the input is short or guessable, nothing stops someone throwing a pile of candidates at it until one digest matches.
Why include MD5 if it is weak?
Because the real world is littered with MD5 checksums people published years back and never bothered to update. You still need to check things against them. I tag it legacy so you can do exactly that, without anyone wandering off convinced MD5 is secure. It isn't.
When should I use HMAC?
Reach for HMAC when you need to prove a message came from someone who actually holds the shared secret, not just that the bytes survived the trip unchanged. Webhook signatures are the classic case. Or a quick internal API example where both sides already share the key.
Which hash should I use to store passwords?
None of the ones on this page. Use a slow KDF built for the job: bcrypt, scrypt, Argon2. MD5 and the whole SHA family are built for raw speed, and speed is precisely what hands an attacker billions of guesses every second. Exactly backwards from what you want here.
What is the difference between a hash and a checksum?
A plain checksum like CRC32 exists to catch accidents. A flipped bit from a flaky cable, a download that got truncated halfway. A cryptographic hash like SHA-256 catches all of that as well, but it keeps holding up when someone's deliberately trying to slip a tampered file past you. That second part is the whole reason it costs more to compute.