Hash Generator

Type something in the box and you get all five hashes at once, MD5, SHA-1, SHA-256, SHA-384, and SHA-512, live, with no Generate button to hit. Each row also tells you where that algorithm stands: MD5 is flagged as legacy, SHA-1 as deprecated, SHA-256 as the current default. That last bit is the reason this page exists. Most hash tools hand you a single dropdown and make you go read a separate article to find out whether the one you picked is still safe to trust. Here the verdict sits right next to the hash.

It's free, no sign-up, and your text never leaves the browser. Paste abc and SHA-256 comes back as ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, same input same output, every time, on any machine. The tool also prints the character count and the byte count under the box, which sounds trivial until your hash disagrees with someone else's and you need to know why.

1. Type or paste into the box up top. The hashes recompute the instant you type, there's no button and no wait.
2. Read down the five rows. Each shows the algorithm, its bit length, and a short note on its security status.
3. Copy the one you need with the Copy button on its row. Straight onto your clipboard, ready to paste.
4. Comparing against a published hash? Put theirs somewhere alongside and check it character for character against the matching row here.

No account, no upload dialog. Once the page has loaded you can even go offline and it keeps working, because the computing happens on your own machine.

MD5 and SHA-1 are broken, and they're also completely fine for the thing most people actually use them for, and both of those are true at once. The difference is whether someone is trying to trick you.

MD5 has been thoroughly broken for years. Researchers can produce two different files with the same MD5 on a laptop in seconds, and there's a chosen-prefix version of the attack, which means an attacker can start from two files they care about (a clean installer and a poisoned one) and massage the bytes until the MD5s collide, and this is not just a theoretical worry. The Flame malware back in 2012 forged a Microsoft code-signing certificate off an MD5 collision and passed itself off as a legitimate Windows update. SHA-1 fell the same way, just at higher cost, when a Google-led team produced two different PDFs with a matching SHA-1 in 2017. That's why Git has been migrating off it and why browsers stopped trusting SHA-1 certificates.

So why keep them in the tool at all? Because collision resistance only matters when there's an adversary in the picture. Take the adversary away and MD5 is a fast, perfectly good checksum. Checking whether a file got mangled in transit, a flipped bit, a truncated copy, a flaky download? Random corruption is never going to stumble onto a collision by accident. That only happens when someone builds one on purpose. Deduping your own files by hash, keying a cache off content you control, a quick "did this config change" check in a script, all fine.

If someone could gain by making two different things look identical, don't trust MD5 or SHA-1. Signatures, security tokens, certificates, anything where trust rides on the hash, reach for SHA-256 or wider. But for spotting accidental damage where nobody's out to get you, the "broken" algorithms still do the job perfectly well.

For anything new, SHA-256 is the sane default. Need more margin? SHA-384 and SHA-512 give you a wider output, and on 64-bit hardware SHA-512 is often faster than SHA-256 because it works in bigger words. The primary spec lives in NIST FIPS 180-4 if you want it straight from the source.

The most common real problem people bring to a hash tool has nothing to do with making a hash. It's "why is mine different from the one I'm comparing against." Nine times out of ten it's one of two things, and neither is the tool being wrong.

First, encoding. A hash function doesn't hash characters, it hashes bytes. Encode the same visible text two different ways and you get two different runs of bytes, which then hash to two different results. This page encodes your input as UTF-8, the near-universal default. But if the other system used UTF-16, or Latin-1, or slipped a byte-order mark in front, or your string carries an emoji or an accented letter that got encoded a different way, the byte streams diverge and so do the hashes, even though the two strings look identical on screen. That character-and-byte count under the box is there so you can catch this. If your eight visible characters read as more than eight bytes, something's encoded wider than you think.

Second, the trailing newline. Type password in the box here and you get one hash. Run echo password | sha256sum in a terminal and you get a different one, because echo tacks a newline on the end, so you actually hashed nine bytes, not eight. Use echo -n or printf to drop it. When two tools disagree, check for a stray newline and a hidden encoding difference before you assume either tool is broken, because one of those two is almost always the entire explanation.

Related trap, and it's a common one: don't hash a file by pasting its text into a web box. Copy-paste quietly rewrites line endings, encoding, and that trailing newline, so you'll get a different answer than sha256sum or PowerShell's Get-FileHash reads off the raw bytes on disk. Use this page for a real string, and for an actual file, hash the file itself with a command-line tool.