Choosing a hash algorithm: MD5, SHA-1, SHA-256, SHA-512, and HMAC

Both have practical, demonstrated collision attacks — meaning an attacker can construct two different inputs that hash to the same output. That makes both unsuitable for anything where collision resistance is the actual security property you’re relying on: digital signatures, certificate fingerprinting, or any scheme where forging a matching hash would let an attacker substitute content. They remain fine for purposes that don’t depend on collision resistance at all — a quick file-integrity check against accidental corruption, or deduplication where the cost of a rare, non-adversarial collision is low. The distinction is the threat model, not the algorithm’s age alone.

Both are part of the SHA-2 family, with no known practical collision attacks. SHA-256 and SHA-512 differ mainly in output size and the word size they operate on internally (SHA-512 tends to be faster on 64-bit hardware despite producing a longer digest) — for most general-purpose use, either is a reasonable default, and the choice between them usually comes down to whatever a spec or existing system already expects rather than a meaningful security difference between the two.

A plain hash proves integrity — that data wasn’t altered — but proves nothing about who produced it, since anyone can compute a hash of anything with no secret involved. HMAC (a keyed-hash construction) combines the message with a shared secret key before hashing, so only someone who holds that key could have produced a given HMAC value. That’s the actual security property needed for verifying a webhook payload, an API request signature, or any scenario where you need to confirm a message came from someone who holds a specific secret — not just that the bytes are intact. Reaching for a bare hash when what you actually need is authentication is one of the more common mix-ups in this space.

Generate a plain digest with the Hash Generator, or a keyed digest for message authentication with the HMAC Generator.