Hash Generator

🟢📖 Hash Algorithm Comparison

🔐 A fingerprint, not a lock

"Hash" gets used for two jobs that have opposite requirements, and the confusion is where most security bugs begin. A checksum answers did this file change? A password hash answers is this person who they claim to be? Both produce a fixed-length digest, but everything else about them differs.

A checksum may be fast, unsalted, and even weak — MD5 is still perfectly serviceable for spotting a truncated download. A password hash must be slow and salted. SHA-256 is a poor password hash for the same reason it is an excellent checksum: commodity hardware computes it at absurd speed. A single RTX 4090 sustains roughly 20 billion SHA-256 hashes per second. Against an 8-character lowercase password there are 26^8 = 208 billion candidates, so the entire space falls in about 10 seconds. Run the same search against bcrypt at cost factor 12 — roughly 250 ms per attempt — and it takes over 1,600 years.

Salting changes the attack, not the speed. A salt does not make guessing one password slower; it makes precomputation worthless. Unsalted, a single rainbow table cracks every account it contains at once. Salted per user, the attacker must redo the full search for each account individually. That is the whole point, and it is why "we hash passwords with SHA-256 plus a salt" is still the wrong answer.

⚠️ Why hash(secret + message) is not authentication

A common way to sign an API request is to concatenate a shared secret with the payload and hash the result: sig = SHA256(secret + message). It looks sound. It is forgeable.

MD5, SHA-1 and the SHA-2 family all use the Merkle–Damgård construction, which means the digest is a function of the algorithm's final internal state — and that state is fully recoverable from the digest. An attacker who knows hash(secret + message) and can guess the length of secret can compute hash(secret + message + padding + extra) for any extra they choose, without ever learning the secret. The padding is deterministic: a 0x80 byte, zero fill, then the total bit length as a 64-bit integer. Guessing the secret length means trying values from 1 to 64 — 64 attempts, not a brute-force search.

HMAC exists precisely to close this. It hashes the message twice, with the key mixed in at both ends, so the internal state an attacker recovers is useless for extending anything. SHA-3 sidesteps the issue structurally — its sponge construction has no such extension property — but HMAC-SHA256 remains the correct default for request signing, and it is what the HMAC toggle on this page computes.

📏 Digest length, storage, and comparison

The digest is raw bytes; what you store is an encoding of them. SHA-256 produces 32 bytes, which is 64 hex characters or 44 Base64 characters including one = of padding. Hex is the convention everywhere, but the encoding you pick changes the column width you need:

• MD5 — 16 bytes → 32 hex chars
• SHA-1 — 20 bytes → 40 hex chars (this is why Git object IDs are 40 characters)
• SHA-256 — 32 bytes → 64 hex chars
• SHA-512 — 64 bytes → 128 hex chars

Two mistakes show up in production. The first is comparing digests with a plain string equality check: == in most languages short-circuits on the first differing byte, so the time it takes to reject a guess leaks how many leading bytes were correct. That is a real (if narrow) side channel; use a constant-time comparison such as hmac.compare_digest() instead. The second is case: this tool emits lowercase hex, most tools do, but a value pasted from a Java BigInteger.toString(16) or a certificate fingerprint may arrive uppercase. Normalise before comparing, or you will reject correct hashes.

See also: Base64 Encode/Decode · Password Crack Estimator · JWT Decoder · Number Base Converter