How to use Hash Generator (MD5/SHA-1/256/512)
What it does & when you need it
You need the MD5, SHA-1, SHA-256, or SHA-512 digest of some text — to verify a download matches a published checksum, to generate a cache key, to compare two blobs of content, or to check a value against a hash someone gave you. This tool computes all four at once, in your browser, so the text you hash never touches a server. SHA digests come from the browser's built-in Web Crypto; MD5 is computed by a small pure-JavaScript implementation because it has no Web Crypto equivalent.
How to use
- Type or paste text into the text to hash buffer, or press Sample. You can also Upload a text file.
- All four digests update live. Each row has its own Copy button; the
toolbar's Copy SHA-256 (or
Ctrl/Cmd+Enter) grabs the most common one. - Compare a digest against the checksum you were given — they should match character for character (hashing is case-sensitive in its output hex).
Things worth knowing
MD5 and SHA-1 are broken for security. Practical collision attacks exist for both — an attacker can craft two different inputs with the same digest. Never use them for signatures, certificates, or anything an adversary can influence. They remain perfectly fine for non-adversarial uses: detecting accidental corruption, deduplicating files, or building a cache key.
Use SHA-256 for integrity. When you download a release and the project
publishes a SHA256SUMS file, hashing the file and comparing is what proves it
arrived intact. SHA-256 (and SHA-512) have no known practical collisions.
Hashing is one-way and is not encryption. There is no key and no "unhash" button — you cannot recover the input from the digest. What you can do is guess: if the input space is small (a short password, a known list), an attacker precomputes hashes (a rainbow table) and looks yours up. That is why hashing a password with raw SHA-256 is unsafe.
For passwords, use a slow salted KDF. bcrypt, scrypt, or Argon2 add a random salt (defeating rainbow tables) and are deliberately slow (defeating brute force). A fast hash like SHA-256 is the wrong tool for storing passwords — reach for a bcrypt tool instead.
Same input, same digest — always. Hashes are deterministic, and they have an avalanche effect: flip one bit of input and roughly half the output bits change. That is why a hash is a good fingerprint but a terrible way to hide small differences. Note also that digests here are shown as lowercase hex; the same bytes are sometimes published as Base64, so if a checksum looks unfamiliar, decode the Base64 first. When you just need a unique identifier rather than a content fingerprint, a UUID is usually the better choice, and strong passwords should be generated, never derived from a plain hash.