SHA-256 Hash Generator

No. SHA-256 is a one-way function with no decryption. The only "attacks" are brute force (guessing inputs until the hash matches) or rainbow tables (precomputed lookups — defeated by salting). If someone claims to "decrypt" a SHA-256 hash, they either guessed the input or the input was a known word.

Output size (256 vs 512 bits) and internal structure. SHA-512 uses 64-bit words, which makes it faster than SHA-256 on 64-bit CPUs for large inputs — but its output is twice as long. SHA-384 is SHA-512 with a truncated output, used where 256 bits feels too short but 512 is overkill. For most applications, SHA-256 is the right default.

Yes. The hash is computed with crypto.subtle.digest() — the browser's built-in Web Crypto API. Your input never leaves the page: there is no network request, no upload, no server. You can even disconnect from the internet and it still works.

Both have practical collision attacks: two different inputs that produce the same hash. MD5 collisions were demonstrated in 2004 and can be computed in seconds on a laptop; SHA-1 collisions (SHAttered, 2017) cost about $110K in cloud compute. If an attacker can produce a "matching" hash for malicious content, integrity checks fail silently. Use SHA-2 (SHA-256/384/512) for anything new.

HMAC is a keyed hash: it mixes a secret key into the hashing process so only parties who know the key can produce or verify the digest. It's the standard way to sign API requests and webhooks — a request carrying a valid HMAC could only have been signed by someone holding the shared secret.

Usually neither: the bytes differ, not the algorithm. Check these four suspects in order. 1. Trailing newline — echo "hello" appends one, so the hash won't match the string you typed; use echo -n or printf. 2. CRLF vs LF — a Windows editor writes \r\n line endings while browsers normalize pasted text to \n, so the same "formatted JSON" can legitimately hash two different ways. 3. Encoding — the same text as UTF-8 and UTF-16 is different bytes, and a BOM adds three more. 4. Output format — hex vs Base64, upper vs lower case. Quick diagnostic: compare the byte lengths of the two inputs before comparing hashes. If the lengths differ, it's whitespace or encoding — the hash function is fine.

All three ship it in the standard library. Python: hashlib.sha256(b"hello").hexdigest(). Node.js: crypto.createHash('sha256').update('hello').digest('hex'). Shell: sha256sum file.zip on Linux, or shasum -a 256 file.zip on macOS. For files larger than a few MB, stream the bytes instead of loading the whole file into memory — the browser tool above already does this, so it stays snappy on multi-gigabyte files.

No — and that shortcut is a real vulnerability. MD5, SHA-1 and SHA-256 all use the Merkle–Damgård construction, which is vulnerable to a length-extension attack: anyone who sees hash(secret || message) can compute hash(secret || message || padding || extra) without ever learning the secret, because the internal state after the first block is exactly what the published digest exposes. So an attacker can append &admin=true to a signed request and forge a valid signature. HMAC defeats this by hashing twice — H(K ⊕ opad || H(K ⊕ ipad || message)) — so the outer hash hides the inner state. Never concatenate a secret with the message; use HMAC-SHA256 and compare MACs in constant time on the server.

In theory yes, in practice no. A 256-bit digest can only hold 2²⁵⁶ distinct values, so collisions must exist — but finding one at random takes roughly 2¹²⁸ attempts (the birthday bound, about 3.4 × 10³⁸ hashes), which is far beyond any feasible computation. That is why SHA-256 is safe for integrity checks and content addressing. The older algorithms are not: MD5 collisions are computed in seconds on a laptop and SHA-1's cost about $110K of cloud compute, so a matching hash from those proves nothing. Need a shorter digest? Truncate SHA-256 instead of switching to MD5 — 128 bits is the accepted floor for collision resistance.

Because the bytes you hashed were the same — usually because a composite key was built by plain string concatenation. Hashing tenant + userId makes ("acme", "42") and ("acm", "e42") both become acme42, so both produce the identical digest 7c187954…3c1fda and one tenant can read the other's cached entry. The hash is not broken; your encoding is ambiguous. Fix it before hashing: join the parts with a separator that cannot appear inside them (acme-42 → d3f5d66e…), length-prefix every field (3:acme2:42), or hash a canonical serialization instead of a hand-built string.

Yes. The digest covers the exact bytes, and key order plus whitespace are part of those bytes: {"a": 1, "b": 2} hashes to d8497d9d…, {"b": 2, "a": 1} to d5b8aed2…, and the compact form {"a":1,"b":2} to 43258cff… — three digests for one object. That is why a payload signature created in Node can fail to verify in Go or Python: each language serializes differently. Canonicalize first — sort keys recursively, use compact separators, and agree on number formatting (RFC 8785 / JCS does exactly this) — then hash the canonical bytes on both sides.