Hash Generator — MD5, SHA-1, SHA-256, SHA-512
Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from any text instantly — computed in your browser, nothing uploaded.
We use cookies and similar technologies to enhance your browsing experience, analyze site traffic, and personalize content and ads. By clicking "Accept", you consent to our use of cookies. Learn more in our Privacy Policy.
Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from any text instantly — computed in your browser, nothing uploaded.
Hash Generator computes cryptographic hashes of any text you paste in: MD5, SHA-1, SHA-256, and SHA-512. Type or paste a string and you get its digest in hexadecimal for each algorithm, ready to copy. A hash is a fixed-length fingerprint of the input. The same input always yields the same hash, and any change to the input, even one character, produces a completely different digest. This makes hashes handy for verifying data hasn't changed, comparing values without storing the originals, and generating stable identifiers.
Everything runs in your browser. The text you enter is hashed locally using the browser's built-in crypto APIs, so nothing is sent to a server. That matters when you're hashing config values, tokens, or anything you'd rather not paste into a remote tool. There's no signup, no upload, and the page works offline once loaded.
Paste or type into the input box and the four digests update as you type. Each algorithm is computed independently from the same input bytes:
Text is encoded as UTF-8 before hashing, which is the standard most other tools use, so your results will match command-line utilities and language libraries that also encode UTF-8. Each result has a copy button. Because the work happens on your machine, the speed depends on your device, but even large inputs hash near-instantly for typical text sizes.
Hash the exact string hello (five lowercase letters, no quotes, no trailing newline) and you'll get these well-known values:
5d41402abc4b2a76b9719d911017c592aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824These are stable reference values. If your terminal gives the same SHA-256 for hello, your encoding matches. A common surprise: echo hello in a shell appends a newline, so echo hello | sha256sum hashes hello\n and gives a different digest. Use printf 'hello' or echo -n hello to hash the bare string. Try changing one letter to Hello and watch every digest change entirely; that sensitivity is the whole point.
Note what hashing is not for: it doesn't encrypt anything. A hash is one-way, so you can't recover the original text from the digest, and it's not a substitute for encryption when you need to protect and later read the data back.
Trailing newlines and whitespace count. A space or \n you didn't notice changes the hash. If your result doesn't match another tool, check for an extra newline first.
Encoding matters. This tool hashes UTF-8 bytes. If another tool used UTF-16 or Latin-1, digests for non-ASCII text won't match even with the same algorithm.
Hashing is not encryption and not password storage. For storing passwords you need a slow, salted password hashing function (such as bcrypt, scrypt, or Argon2), not a raw MD5 or SHA digest. Plain SHA-256 of a password is fast to brute-force.
Pick the right algorithm for the job. Use SHA-256 as a sensible default for integrity and identifiers. MD5 and SHA-1 are fine for non-security checksums but are broken for anything where an attacker might try to forge a collision.
A collision is two different inputs that produce the same hash. A secure hash should make finding one computationally infeasible. MD5 and SHA-1 no longer meet that bar: practical collisions have been demonstrated for both, meaning an attacker can craft two distinct files with the same digest. That breaks any use where the hash is meant to prove authenticity, such as signatures or security tokens.
They remain useful for non-adversarial tasks: verifying an accidental change during a download, generating a quick fingerprint, or matching against legacy systems that already use them. The danger is only when someone has an incentive to forge a match.
For anything security-sensitive, prefer SHA-256 or SHA-512 from the SHA-2 family, which currently have no practical collision attacks. When you specifically need keyed integrity, use an HMAC built on SHA-256 rather than a bare hash.
They differ in output length (128, 160, 256, and 512 bits) and in security. MD5 and SHA-1 are broken against collision attacks and should be used only for non-security checksums, while SHA-256 and SHA-512 remain secure for integrity and identifiers.
No. Hashing runs entirely in your browser using its built-in crypto APIs, so the input never leaves your device and the page works offline once loaded.
No. Hashes are one-way functions, so there is no way to reverse a digest back into the input. Anyone claiming to 'decrypt' a hash is really just looking it up in a precomputed table of common values.
The most common cause is a trailing newline; echo adds one, so use printf 'text' or echo -n. The second most common cause is a different text encoding, since this tool hashes UTF-8 bytes.
None of these directly. Use a dedicated password hashing function such as bcrypt, scrypt, or Argon2, which are deliberately slow and salted. Raw MD5 or SHA-256 hashes are far too fast and are unsafe for passwords.
Only for non-adversarial checks like detecting accidental file corruption. MD5 has practical collision attacks, so it must not be used where someone could benefit from forging a matching hash.
Yes. A given input and algorithm always produce the same digest, which is why hashes work as stable fingerprints. Any change to the input, even one character or a stray space, changes the result completely.
A collision is two different inputs that produce the same hash. Secure hashes make finding one infeasible; MD5 and SHA-1 have known practical collisions, which is why they should not be trusted for authenticity.