Hash Generator

What a hash actually is

A hash function takes any input, a word, a password, a ten-gigabyte file, and turns it into a fixed-length string of characters, the digest. The same input always produces the same digest. Change even one byte of the input and the digest comes out completely different, not just slightly different, which is what makes hashes useful for spotting any change at all, however small.

That property is why hashes show up everywhere: checking that a downloaded file wasn't corrupted in transit, detecting whether a piece of data changed, or turning a large piece of data into a short one you can compare quickly instead of comparing the whole thing byte by byte.

Why MD5 and SHA-1 aren't for security anymore

MD5 and SHA-1 are both broken for security purposes. Researchers can deliberately construct two different inputs that hash to the same MD5 or SHA-1 digest, a collision, which defeats the entire point of using a hash to guarantee something hasn't been tampered with. That's why modern certificates, signatures, and password storage have all moved to SHA-256 or stronger.

The honest caveat: broken for security doesn't mean useless. If you're checking that a file downloaded correctly, or that two copies of a build artifact are identical, nobody is trying to forge a matching MD5 on purpose, so it's still a perfectly fine checksum for that. The line is whether an adversary benefits from finding a collision. If yes, use SHA-256 or better. If it's just accidental-corruption detection, MD5 and SHA-1 remain fine, which is why both are still offered here alongside the SHA-2 family.

What HMAC is, and why concatenating the secret doesn't work

The obvious-seeming way to prove a message came from someone who knows a secret is to hash the secret glued onto the message, hash(secret + message). It's also broken. Because of how hash functions like SHA-256 are built internally, an attacker who sees hash(secret + message) can often compute hash(secret + message + extra) without ever knowing the secret, a length extension attack, and use it to forge a valid signature for a message you never approved.

HMAC is the construction designed to close that hole. Instead of one hash call, it runs the key and message through the hash function twice in a specific nested pattern (roughly hash(key XOR opad + hash(key XOR ipad + message))) that's proven to resist that kind of forgery. This is why every real API, Stripe, GitHub, Shopify, Twilio, signs webhook payloads with HMAC and never with a plain concatenated hash.

Broken:  hash(secret + message)          — vulnerable to length extension
Correct: HMAC(secret, message)           — hash(key ⊕ opad + hash(key ⊕ ipad + message))

Generate vs Verify — the mode most people don't know is here

Generate is what everyone expects from a hash tool: paste something, get a hash back. Verify does the opposite job, and it's the one webhook integrations actually need. A service like Stripe sends you a payload plus a signature in a header. Your job isn't to generate a hash, it's to recompute the HMAC yourself with your shared secret and check whether it matches what they sent. If it matches, the payload is genuinely from them and untampered. If it doesn't, someone (or something) altered it, or you're using the wrong secret or algorithm.

Verify also matters because comparing signatures the naive way, with ===, can leak timing information an attacker could exploit to guess a signature one byte at a time. This tool compares every byte instead of stopping at the first mismatch, so the comparison takes the same time whether the signature is correct, close, or completely wrong.