Hash generator

What this tool does

Type or paste anything into the box and every digest below updates as you type: MD5, SHA-1, SHA-256, SHA-224, SHA-512, SHA-384, SHA3-256 and RIPEMD-160, all of the same input, side by side. Each row can be copied on its own, and the hex can be switched to upper case for the systems that print it that way.

Seeing eight algorithms at once is more useful than it sounds. Most of the time you are not choosing an algorithm — you are trying to work out which one produced a value somebody handed you, or checking that what your code computes matches what a specification says it should. A 32-character hex string is MD5, 40 is SHA-1 or RIPEMD-160, 64 is SHA-256 or SHA3-256, 96 is SHA-384 and 128 is SHA-512. Pasting the original text here and comparing rows settles it in a second.

The input is treated as UTF-8 bytes, which is what almost everything else does too, and the byte count next to the buttons shows how many bytes that actually is — a useful reminder that an accented character or an emoji is more than one byte, and that hashing "café" is not hashing four bytes.

What a hash is, and what it is not

A cryptographic hash takes an input of any size and produces a fixed-length fingerprint of it. The same input always gives the same digest, a single changed bit gives a completely different one, and the function is designed so that you cannot work backwards from the digest to the input, or find two inputs that produce the same digest.

The most common misunderstanding is worth stating plainly: hashing is not encryption. Encryption is reversible by design — that is the point of it — and hashing is not reversible at all. There is no key, no decrypt operation and no way to recover the input from the output. What people mean when they say a hash was "cracked" is that someone guessed an input that produces the same digest, usually by trying billions of likely candidates, which is a very different thing from reversing the function.

That distinction decides what hashes are good for: verifying that something has not changed, comparing two things without revealing them, indexing content by what it contains rather than by name, and building signatures and message authentication codes. It also decides what they are bad for, which is the next chapter.

Which one should you use?

For anything new, SHA-256. It is fast, universally implemented, and has no known practical weakness; unless something in your stack demands otherwise, it is the default that requires no justification. SHA-512 is not "more secure" in any way that matters for most uses, but it is often faster on 64-bit hardware and gives a longer digest where you want one. SHA-384 is SHA-512 truncated, and exists mainly because some standards specify it. SHA-224 is the same idea applied to SHA-256, and is rare outside specific protocols.

SHA3-256 is not a replacement for SHA-256 and not an upgrade to it — it is a different construction, chosen through a public competition, deliberately built on completely different mathematics. Its purpose is insurance: if a structural flaw were ever found in the SHA-2 family, SHA-3 would not inherit it. Use it when a specification asks for it, or when you want that independence on purpose.

RIPEMD-160 is a European design from the same era as SHA-1 that has aged much better, and survives mostly because Bitcoin addresses are built from it. If you are not working with cryptocurrency, you almost certainly do not need it.

MD5 and SHA-1 are broken and marked as legacy above for that reason. Collisions — two different inputs with the same digest — can be produced deliberately, cheaply and on demand; this has been demonstrated in the wild against both. They are not safe for signatures, certificates, deduplication where an attacker controls the input, or anything a security decision depends on. They remain perfectly reasonable as non-security checksums against accidental corruption, and as identifiers in legacy systems that have no attacker in the model, which is why they are still here.

Never hash a password with these

This is the mistake that keeps showing up in breach reports, so it deserves its own chapter. If you are storing passwords, none of the algorithms on this page is the right tool — not even SHA-512, not even with a salt.

The reason is speed. Every algorithm here is designed to be as fast as possible, which is exactly what you want for verifying a download and exactly what you do not want for a password. Modern hardware computes billions of SHA-256 digests per second, so a stolen table of fast hashes can be attacked at a rate that turns most real-world passwords into plaintext in hours. Adding a salt stops precomputed rainbow tables and forces the attacker to work on one account at a time; it does nothing about the speed.

What you want is a deliberately slow, memory-hard function built for the job: Argon2id for new systems, bcrypt or scrypt where that is what your platform offers. They take a tunable amount of time and memory per attempt, which is imperceptible when a user logs in and ruinous when someone is trying a dictionary. Every serious framework ships one — in PHP it is password_hash(), and in practice you should never be writing the hashing step yourself.

Where hashes earn their keep

File and download integrity. A published SHA-256 next to a download lets you confirm that what arrived is what was published. Note what this does and does not prove: it detects corruption and interception in transit, but if an attacker controls the page, they control the checksum printed on it too — which is why signatures, not bare checksums, are what protect a software supply chain.

Change detection. Hashing a record, a configuration file or a rendered document gives you a cheap way to answer "is this the same as last time" without storing or comparing the whole thing. Content-addressed systems — Git commits, container layers, deduplicating backups — are this idea taken to its conclusion: the digest is the identifier.

Comparing without revealing. Two parties can compare digests to see whether they hold the same value without either handing the value over. This is genuinely useful, and also frequently misused: for a low-entropy input such as an email address or a phone number, the digest is not anonymous at all, because anyone can hash every candidate and look up the answer. Hashing an email address does not de-identify it.

Signatures and message authentication. Digital signatures sign a digest rather than the document, and HMAC uses a hash plus a secret key to prove that a message came from someone holding that key and has not been altered. Both are why a collision attack on the underlying hash is such a serious event — and why MD5 and SHA-1 are no longer acceptable anywhere near either.

Nothing you type leaves your browser

Every digest on this page is computed locally. The SHA family comes from your browser own crypto.subtle implementation; MD5, SHA-224, SHA3-256 and RIPEMD-160 are computed by the script on this page. Nothing you type becomes a network request: no upload, no cookie, no local storage, no log.

That matters here more than on most tools, because of what people paste into a hash box. Working out why a signature does not verify means pasting the exact string that was signed — an API payload, a session token, a shared secret, a customer record. On a server-side hash tool, all of that is now in somebody else's request log, and the digest you got back is proof of nothing about what happened to the input.

Check it rather than take it on faith: open your network tab and type. Beyond the analytics beacon this site sends on every page load — a URL and a page title, the same as any other page here — nothing is sent, whatever you paste. Disconnect from the network entirely and the digests still update.

A worked example

Type abc and compare the rows against the published test vectors, which is the standard way to check any implementation: MD5 gives 900150983cd24fb0d6963f7d28e17f72, SHA-1 gives a9993e364706816aba3e25717850c26c9cd0d89d, SHA-256 gives ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, SHA3-256 gives 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532 and RIPEMD-160 gives 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc.

Now add a single full stop and watch every row change completely rather than slightly. That property — a one-bit change producing an unrecognisably different digest — is called the avalanche effect, and it is what makes a hash useful for detecting change: there is no such thing as two digests being "nearly" equal, and no information about how similar the inputs were.