SHA-256 — sensible default for integrity checks, content addressing (Git, IPFS-style), HMAC keys, and signatures. SHA-384 / SHA-512 — useful when you need a wider digest (PBKDF2/HKDF tuning, larger HMAC keys, post-quantum-margin habits). SHA-1 — for compatibility only (Git object IDs, legacy CI checksums). Don't use for security boundaries — practical collision attacks have existed since 2017.

Hashing is not encryption. Hashes are one-way; you can't get the original back. If you need confidentiality, encrypt. Don't hash passwords with raw SHA-256. Plain SHA is fast — that helps attackers brute-force. Use a slow KDF (Argon2id, bcrypt, scrypt) for password storage. MD5 is intentionally absent. Broken since the early 2000s. Anywhere you "need" MD5, you also need to flag a security review. Whitespace matters. A trailing newline produces a different hash than the same text without one. Compare hex output exactly.

Hash function choice is purpose-driven, not "best". SHA-256 for integrity and signatures. SHA-1 only where a legacy protocol mandates it (Git object IDs, older TLS — both deprecated for new use). Argon2id or bcrypt for password storage. xxHash or BLAKE3 for non-cryptographic deduplication where speed matters more than collision resistance. The wrong function for the job either burns CPU or burns security. "Fast" is a misfeature for passwords. SHA-256 hashes about 500 million inputs per second on a modern GPU. A password leak hashed with raw SHA-256 is, for any password under ~12 random characters, fully crackable in hours. Password-specific KDFs (Argon2id, bcrypt, scrypt) deliberately run thousands of times slower per attempt — that's the entire point. If a "password hash" function isn't slow, it's the wrong function. The collision-resistance ladder. MD5 (broken 2004, find collisions in seconds). SHA-1 (broken 2017, find collisions in ~6500 CPU-years but practical for state actors). SHA-256 (no known collisions, considered safe for the foreseeable future). SHA-3 / Keccak (newer construction, different design assumptions — useful when SHA-2 family is considered too monoculture). For 2026 greenfield work, default to SHA-256 unless you have a reason otherwise. HMAC, not concatenation. Authenticating a message with hash(secret + message) is vulnerable to length-extension attacks on SHA-1 and SHA-2. The correct primitive is HMAC, which uses two passes of the hash with the key XOR'd against fixed pads. Every "I rolled my own auth code with SHA-256" is potentially exploitable in this way; use the HMAC-SHA-256 function the platform provides. Salt the hash, even for non-passwords. Deduplicating files by SHA-256 across multiple users? Two users with the same file get the same hash, exposing that fact. Privacy-sensitive deduplication needs a per-user (or per-tenant) salt so users with identical files don't reveal it to the system operator. Hash uniqueness is feature; hash equality across users is information leak.

Hash Generator

Hash text with SHA-1, SHA-256, SHA-384 or SHA-512 using your browser's WebCrypto. Computed locally — input never leaves the page.

Input

Note: MD5 is not provided here — it is broken for security purposes. Use SHA-256 or higher for new applications.

SHA-1 160 bits — legacy, do not use for security

Enter input above to see the result.

SHA-256 256 bits — recommended default

Enter input above to see the result.

SHA-384 384 bits

Enter input above to see the result.

SHA-512 512 bits

Enter input above to see the result.

What is this for?

A cryptographic hash takes any input and produces a fixed-length fingerprint. Two identical inputs always hash to the same digest; changing a single bit changes the digest entirely. Hashes underpin file-integrity checks, content-addressable storage, digital signatures, and password-hashing pipelines (where they're combined with a slow function like Argon2 or bcrypt).

All hashing here uses the browser's crypto.subtle.digest — the same primitives that power TLS. Your input never leaves the page.

When to use which

SHA-256 — sensible default for integrity checks, content addressing (Git, IPFS-style), HMAC keys, and signatures.
SHA-384 / SHA-512 — useful when you need a wider digest (PBKDF2/HKDF tuning, larger HMAC keys, post-quantum-margin habits).
SHA-1 — for compatibility only (Git object IDs, legacy CI checksums). Don't use for security boundaries — practical collision attacks have existed since 2017.

Common gotchas

Hashing is not encryption. Hashes are one-way; you can't get the original back. If you need confidentiality, encrypt.
Don't hash passwords with raw SHA-256. Plain SHA is fast — that helps attackers brute-force. Use a slow KDF (Argon2id, bcrypt, scrypt) for password storage.
MD5 is intentionally absent. Broken since the early 2000s. Anywhere you "need" MD5, you also need to flag a security review.
Whitespace matters. A trailing newline produces a different hash than the same text without one. Compare hex output exactly.

Expert notes

Hash function choice is purpose-driven, not "best". SHA-256 for integrity and signatures. SHA-1 only where a legacy protocol mandates it (Git object IDs, older TLS — both deprecated for new use). Argon2id or bcrypt for password storage. xxHash or BLAKE3 for non-cryptographic deduplication where speed matters more than collision resistance. The wrong function for the job either burns CPU or burns security.
"Fast" is a misfeature for passwords. SHA-256 hashes about 500 million inputs per second on a modern GPU. A password leak hashed with raw SHA-256 is, for any password under ~12 random characters, fully crackable in hours. Password-specific KDFs (Argon2id, bcrypt, scrypt) deliberately run thousands of times slower per attempt — that's the entire point. If a "password hash" function isn't slow, it's the wrong function.
The collision-resistance ladder. MD5 (broken 2004, find collisions in seconds). SHA-1 (broken 2017, find collisions in ~6500 CPU-years but practical for state actors). SHA-256 (no known collisions, considered safe for the foreseeable future). SHA-3 / Keccak (newer construction, different design assumptions — useful when SHA-2 family is considered too monoculture). For 2026 greenfield work, default to SHA-256 unless you have a reason otherwise.
HMAC, not concatenation. Authenticating a message with hash(secret + message) is vulnerable to length-extension attacks on SHA-1 and SHA-2. The correct primitive is HMAC, which uses two passes of the hash with the key XOR'd against fixed pads. Every "I rolled my own auth code with SHA-256" is potentially exploitable in this way; use the HMAC-SHA-256 function the platform provides.
Salt the hash, even for non-passwords. Deduplicating files by SHA-256 across multiple users? Two users with the same file get the same hash, exposing that fact. Privacy-sensitive deduplication needs a per-user (or per-tenant) salt so users with identical files don't reveal it to the system operator. Hash uniqueness is feature; hash equality across users is information leak.