Hash Generator

Choosing an algorithm: SHA-256 vs SHA-512

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.

SHA-256 for almost everything, SHA-1 for almost nothing

• 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.

One-way, not confidential — and other boundaries

• 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.

The collision-resistance ladder and HMAC

• MD5 → SHA-1 → SHA-256 → SHA-3. MD5 (broken 2004, find collisions in seconds). SHA-1 (broken 2017, practical for state actors). SHA-256 (no known collisions, safe for the foreseeable future). SHA-3 / Keccak (newer construction, useful when SHA-2 monoculture is a concern). For 2026 greenfield work, default to SHA-256 unless you have a reason otherwise.
• "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.
• 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.

The avalanche effect in four hex lines

Type hello and it instantly shows four hex digests at once — SHA-1, SHA-256, SHA-384 and SHA-512. The SHA-256 of hello is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Change a single character and every digest changes completely (the avalanche effect), which is exactly what makes hashes useful for verifying that a file or string hasn't been altered.

Missing MD5, text vs bytes, password hashing, and browser privacy

Which algorithms are here, and why not MD5? SHA-1, SHA-256, SHA-384 and SHA-512 — computed with the browser's native Web Crypto engine. MD5 and plain SHA-1 are cryptographically broken for security use; SHA-1 is included for legacy checksum matching only. For anything security-sensitive, use SHA-256 or stronger.

Is the input hashed as text or bytes? Your text is encoded as UTF-8 bytes first, then hashed — so the digest matches what command-line tools produce for the same UTF-8 string, including non-Latin characters and emoji.

Can I hash a password with this? You can, but you shouldn't store passwords as a bare SHA hash — those are designed to be fast, which helps attackers. Password storage needs a slow, salted algorithm like bcrypt, scrypt or Argon2. Use this tool for integrity checks and fingerprints, not credential storage.

Does my input leave the browser? No — hashing happens entirely locally via crypto.subtle. You can safely hash sensitive strings; nothing is uploaded.

Deterministic, one-way, and avalanche-prone

A hash function maps any input to a fixed-length digest, deterministically and one-way: the same input always yields the same output, but the output reveals nothing about the input and can't be reversed. The avalanche property means flipping a single input bit changes about half the output bits, which is why hashes make good integrity checks — any tampering is obvious. Critically, the right function depends on the job: MD5 and SHA-1 are fast and broken for security (collisions are findable), fine only for non-adversarial checksums; SHA-256 is the safe general integrity choice; and passwords need deliberately slow functions like bcrypt or Argon2.

Why speed is the enemy of password hashing

Hashing passwords with a fast general-purpose function like SHA-256. Speed is exactly wrong for passwords — it lets an attacker try billions of guesses per second against a stolen database. Passwords need a slow, salted function (bcrypt, scrypt, Argon2) built to resist brute force. Using MD5 or SHA-1 for anything security-sensitive is the other trap: both are cryptographically dead and must not guard integrity against a motivated adversary.

Related

Generate unique IDs with the UUID generator, create strong secrets with the password generator, and encode raw bytes with the Base64 encoder. Choosing the function: which hash function to use, and for logins, salting and hashing passwords.