Hash Generator
Compute MD5, SHA-1, SHA-256, and more
Hashes update live as you type. 0 bytes input.
What is a hash function?
A hash function takes input data of any size and produces a fixed-length, deterministic fingerprint of it. The same input always produces the same hash; even a one-bit change anywhere in the input produces a wildly different hash. A good cryptographic hash is also one-way — you cannot reverse the output to recover the input — and collision-resistant: it is computationally infeasible to find two different inputs that produce the same hash. Hashes are the building block underneath data integrity checks, content addressing, deduplication, digital signatures, blockchains, and (with caveats) password storage.
This tool computes the most commonly used hashes — MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA-3 (224, 256, 384, 512), and CRC32 — over the UTF-8 bytes of whatever text you paste. The results update live as you type. The cryptographic hashes (SHA-2 and SHA-3 families) are computed by the browser's SubtleCrypto.digest() API, which uses the same constant-time implementations browsers use for HTTPS. MD5, SHA-1, and CRC32 are computed in JavaScript, since they are no longer offered by SubtleCrypto for security reasons. All computation happens in your browser — the input is never sent to a server.
A common confusion is between hashing, encryption, and password hashing. Hashing is one-way and produces a fingerprint; you cannot get the original back. Encryption is reversible with a key — that is the whole point. Password hashing uses a special, deliberately slow class of algorithms (bcrypt, scrypt, Argon2) that resist brute-force guessing; plain SHA-256 is not a password hashing algorithm, even though it is sometimes used that way by mistake. The detail sections below explain when each hash is appropriate and when you should reach for something else.
The hash families, explained
The hashes this tool offers belong to four different families with different design goals and different security properties. Picking the right one matters: a hash that is fine for a checksum is not fine for a signature, and a hash that is fine for a signature is not fine for password storage.
MD5
128-bit · 1992
Designed by Ron Rivest in 1992. Cryptographically broken since 2004 — practical collision attacks let attackers craft two different files with the same MD5. Still useful as a fast non-cryptographic checksum (verifying file transfers, deduplicating identical content, content-addressed caches), but never use it for signatures, certificates, password storage, or anywhere an adversary picks the input.
SHA-1
160-bit · 1995
Designed by the NSA, published as FIPS 180-1 in 1995. Cryptographically broken since 2017 — Google demonstrated a real-world collision (the SHAttered attack) costing around $110,000 in cloud compute. Browsers reject SHA-1 in TLS certificates; major Git hosts have moved or are moving to SHA-256. Still appears in legacy systems and is fine as a non-cryptographic checksum, but should not be used for new security work.
SHA-2 family (SHA-256, SHA-384, SHA-512)
256/384/512-bit · 2001
Designed by the NSA and published as FIPS 180-2 in 2001. The current default for general-purpose cryptographic hashing in 2026 — used by TLS 1.2/1.3, Git's newer object format, Bitcoin (SHA-256), Ethereum (originally), JWT signatures, and most digital-signature schemes. SHA-256 is the right choice when you need a cryptographic hash and have no specific reason to pick something else. SHA-384 and SHA-512 are appropriate when you want extra collision resistance or when 64-bit arithmetic happens to be faster than 32-bit on your platform.
SHA-3 family (Keccak)
224/256/384/512-bit · 2015
Selected through a public NIST competition that ran from 2007 to 2012, standardised in 2015 as FIPS 202. SHA-3 is built on the sponge construction, which is structurally different from the SHA-2 design — chosen as a hedge against a hypothetical future weakness in SHA-2. As of 2026 SHA-2 has held up, so SHA-3 is mostly used in new protocols that want a future-proof primitive (Ethereum 2.0, some post-quantum signature schemes) rather than as a drop-in replacement.
CRC32
32-bit · non-cryptographic
A cyclic redundancy check, not a cryptographic hash. CRC32 is designed to detect accidental bit errors in transmission — used by Ethernet frames, ZIP archives, gzip, PNG, and many file formats. It is fast, small, and good at catching transmission errors, but trivially easy to forge: an attacker who controls the input can produce any CRC32 they like. Use it for accidental-error detection, never for security.
Password-hashing algorithms (NOT in this tool)
bcrypt · scrypt · Argon2
Storing passwords requires a deliberately slow, salted, memory-hard hash designed for the job. Argon2id (PHC winner, 2015) is the current recommendation; bcrypt (1999) and scrypt (2009) remain widely deployed. None of them are offered here because building one in a browser-side tool defeats their purpose — they need server-side parameters and per-user salt. Plain SHA-256 of a password is millions of times faster to brute-force than bcrypt and should not be used.
HMAC and keyed hashes (NOT a hash on its own)
HMAC-SHA256
When you want to authenticate a message — proving that it came from someone holding a shared secret — use HMAC with a cryptographic hash, not the hash directly. Naively concatenating SHA256(key + message) is vulnerable to length-extension attacks; HMAC was designed to avoid them. JWT's HS256 is HMAC-SHA-256.
Which hash to use for what
The right hash depends on what you are protecting against. The table below summarises the conventional choice for common use cases and the reason behind it.
| Use case | Recommended | Why |
|---|---|---|
| File integrity checksum (non-adversarial) | SHA-256 | Standard, fast, no known weaknesses |
| File integrity (legacy compatibility) | MD5 or SHA-1 | Fine when an attacker cannot pick the input |
| Cryptographic signature | SHA-256 / SHA-384 | TLS, JWT, code signing — broken hashes are unsafe |
| HTTPS / TLS certificate digest | SHA-256 | Browsers reject SHA-1 certificates since 2017 |
| Content addressing (Git, IPFS) | SHA-256 | Git's newer format; IPFS default |
| Password storage | Argon2id (or bcrypt) | Plain SHA hashes are too fast to brute-force |
| Session token / API key generation | random bytes from CSPRNG | Hashes need input — generate fresh random |
| Message authentication (MAC) | HMAC-SHA-256 | HMAC, not raw hash, prevents length-extension |
| JWT signing (symmetric) | HS256 = HMAC-SHA-256 | The JWT default; HS512 if you prefer 64-bit |
| JWT signing (asymmetric) | RS256 / ES256 | Public-key signature, not a raw hash |
| Deduplication / cache key | SHA-256 or xxHash | Cryptographic if input is untrusted, else faster non-crypto |
| Network frame / archive checksum | CRC32 | Designed for accidental transmission errors |
| Bitcoin block hash | double SHA-256 | Bitcoin's specific construction |
| Ethereum address hash | Keccak-256 (legacy SHA-3) | Ethereum predates the SHA-3 standardisation tweak |
How the tool computes hashes
Your input is encoded as UTF-8 bytes — the standard text-to-bytes encoding for almost all modern systems — before being passed to the hash function. UTF-8 means that ASCII text is one byte per character, accented Latin characters are two bytes, most non-Latin scripts are three bytes, and emoji are typically four bytes. The "bytes input" counter shows the actual byte count, which is what each hash sees. Cryptographic hashes (SHA-2 family, SHA-3 family) are delegated to the browser's built-in crypto.subtle.digest() API — these run in the browser's native code, in constant time, and use the same implementation paths the browser uses for HTTPS. MD5, SHA-1, and CRC32 are computed by JavaScript implementations included in the page, because crypto.subtle deliberately does not expose them (deprecated for security reasons). All output is rendered as lowercase hexadecimal, the conventional form for hash digests.
Frequently asked questions
Is MD5 still safe?
Should I hash passwords with SHA-256?
What's the difference between SHA-1 and SHA-256?
What's the difference between SHA-2 and SHA-3?
Why is the same input giving different hashes in different tools?
\n that this tool would include but a copy-paste might not; (3) upper-case vs lower-case hex — some tools display in uppercase. Verify the exact bytes: this tool reports the byte count under the input, which is the most reliable cross-check.Are MD5, SHA-1, and CRC32 still "real" hashes?
Is the input sent to a server?
crypto.subtle.digest() API; MD5, SHA-1, and CRC32 are computed by JavaScript on the page itself. The text you paste in never leaves your device, and the tool works offline once the page has loaded.