Hash Generator

What Is a Hash Generator?

A hash generator runs text through a cryptographic hash function and shows the result, a fixed-length string of hex characters called a hash, digest, or checksum. The same input always gives the same hash, and the smallest change gives a completely different one:

SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("Hello") = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

That behavior, called the avalanche effect, is what makes hashes useful. Compare two hashes and you know whether two inputs are identical without comparing the inputs themselves. And because a hash can’t be run backwards, you can publish or store one without revealing what produced it.

This tool supports the five algorithms you’ll meet most often: MD5, SHA-1, SHA-256, SHA-384, and SHA-512.

How to Use the Hash Generator

1. Type or paste text into the input box. The hash updates as you type.
2. Pick an algorithm from the dropdown. SHA-256 is the default, and switching re-hashes the input immediately.
3. Click All Hashes to see every algorithm side by side. That view stays on while you keep typing.
4. Click Copy to put the result on your clipboard.

Keyboard shortcuts: Ctrl+Enter hashes with the selected algorithm, and Ctrl+L clears the input. Your last input is saved in your browser’s local storage, so it’s still there when you come back.

Hash Algorithm Comparison

SHA-256, SHA-384, and SHA-512 all belong to the SHA-2 family. SHA-384 is SHA-512 with different starting values and a shorter output. On 64-bit processors without dedicated SHA instructions, SHA-512 is often faster than SHA-256 because it works on 64-bit words. The newer SHA-3 standard (2015) isn’t in browsers’ Web Crypto API, so this tool doesn’t offer it.

MD5 and SHA-1: Broken, but Not Useless

“Broken” means an attacker can build two different inputs with the same hash. MD5 has been in that state since 2004. In 2012, the Flame malware used an MD5 collision to forge a Microsoft code-signing certificate. SHA-1 followed in 2017, when Google and CWI Amsterdam published two different PDF files with the same SHA-1 hash (the SHAttered attack). In 2020, researchers estimated that a chosen-prefix SHA-1 collision costs about $45,000 in rented GPU time. NIST has told agencies to stop using SHA-1 completely by the end of 2030.

Whether that matters depends on the threat. A collision attack needs someone who controls an input. So:

• Not acceptable: signatures, certificates, software-update checks, or anything where an attacker could swap a file or message for one with the same hash.
• Still acceptable: cache keys, deduplicating your own files, sharding by hash, and catching accidental corruption when a mirror only publishes an MD5 checksum.

Git still uses SHA-1 for object IDs, with collision detection added in 2017, and has supported a SHA-256 repository format since version 2.29. UUID versions 3 and 5 are built from MD5 and SHA-1 hashes of a name. Those are fine for IDs but not for security. The UUID Generator makes random and time-ordered UUIDs instead.

Which Hash Algorithm Should You Use?

• General-purpose fingerprint, checksum, or content ID: SHA-256.
• Matching a checksum someone published: whatever algorithm they used. The hash only means something if you compute it the same way.
• Subresource Integrity (integrity="sha384-..."): SHA-384 is the common choice, but SRI wants the digest in Base64, not hex. Generate it with openssl dgst -sha384 -binary file.js | openssl base64 -A.
• Message authentication or API signatures: HMAC-SHA256, not a bare hash (see below).
• Passwords: none of these. Use a password hashing function.

Hashing vs Encryption vs Encoding

These three get mixed up all the time:

• Encoding (Base64, URL encoding, hex) changes how data is written and is fully reversible by anyone, no key needed. Try the Base64 Encoder/Decoder.
• Encryption (AES, RSA) hides data and is reversible with the right key.
• Hashing can’t be reversed at all. Only someone who already has the input can reproduce the hash.

“MD5 decrypt” sites don’t break this. They keep huge tables of precomputed hashes for common words and leaked passwords and look your hash up. That works on password123, and it’s the main reason never to store a plain, unsalted hash of a password.

Don’t Hash Passwords with SHA-256

SHA-256 is designed to be fast, and fast is bad for passwords: a single modern GPU can test billions of SHA-256 guesses per second against a stolen hash. Password storage needs a function that is slow on purpose and salted, so every user’s hash is unique even when two of them pick the same password. The OWASP Password Storage Cheat Sheet recommends Argon2id first, then scrypt or bcrypt, and PBKDF2 where FIPS-140 compliance is required. Every mainstream language has a maintained library for these. Don’t build your own scheme out of SHA-256 and a loop. And the strongest hash can’t save a weak password, so start with the Password Generator.

HMAC: Hashing with a Secret Key

To prove that a message came from someone who holds a secret key, as with webhook signatures, signed API requests, or HS256 JWTs, use HMAC. Gluing the key onto the message and hashing it is not enough. With MD5, SHA-1, SHA-256, and SHA-512, anyone who knows hash(secret + message) and the secret’s length can compute a valid hash for the message plus extra data, without ever learning the secret. This is called a length-extension attack. HMAC’s two-pass construction prevents it:

Python:   hmac.new(key, msg, hashlib.sha256).hexdigest()
Node.js:  crypto.createHmac('sha256', key).update(msg).digest('hex')

When you verify an HMAC, compare it in constant time with hmac.compare_digest in Python or crypto.timingSafeEqual in Node.js. A plain == can leak how many leading characters matched. The JWT Generator signs tokens with HMAC-SHA256 in your browser.

Why Your Hash Doesn’t Match

When two tools give different hashes for “the same” text, the bytes are different, almost always in a way you can’t see:

• A trailing newline from echo. echo hello | sha256sum hashes hello\n and prints 5891b5b5..., not 2cf24dba.... Use echo -n hello or printf '%s' hello.
• Line endings. A file saved on Windows has CRLF (\r\n) line breaks. Browsers turn every line break in a text box into a plain LF (\n), so pasting a CRLF file here won’t reproduce that file’s hash. Hash the file itself instead.
• Character encoding. This tool, Python’s str.encode(), and Node.js hash UTF-8 bytes. .NET’s Encoding.Unicode and many Windows APIs produce UTF-16, which gives a different hash for the same string.
• Invisible characters. A leading space, a trailing tab, a non-breaking space copied from a web page, or a byte order mark at the start of a file each change the hash completely.
• Output format. Hex case doesn’t matter (2CF24D... equals 2cf24d...), but a Base64 digest of the same hash looks completely different from the hex one.

Verify a File Checksum

This tool hashes text. For a downloaded ISO, installer, or archive, run the hash locally and compare it with the checksum on the publisher’s site:

On Linux, sha256sum -c SHA256SUMS checks every file listed in a checksum file at once. A checksum from the same server as the download only proves the file wasn’t corrupted in transit. To prove the publisher made it, check the signature on the checksum file, usually with GPG.

Generate a Hash in Code

Swap the algorithm name for md5, sha1, sha384, or sha512 to get the others. Note that browsers’ Web Crypto API has no MD5, and crypto.subtle is only available on HTTPS pages and localhost.

Your Data Stays in Your Browser

Everything you type is hashed on your own device. SHA-1, SHA-256, SHA-384, and SHA-512 come from the browser’s built-in Web Crypto API, and MD5 from a small JavaScript implementation on this page. Nothing is uploaded, logged, or stored anywhere except your browser’s local storage, which you can wipe with Ctrl+L.