HMAC Generator (SHA-1 / SHA-256 / SHA-512)

HMAC (Hash-based Message Authentication Code) combines a secret key with a message to produce a tag that proves two things at once: the message has not been altered (integrity) and it came from someone holding the key (authenticity). Unlike a bare hash, an attacker who cannot guess the key cannot forge a valid tag, even if they can see many message/tag pairs.

How it works. HMAC feeds the key and message through a hash function twice with distinct padding constants (ipad and opad). That two-pass construction is what makes it resistant to the length-extension attacks that affect naive hash(secret + message) schemes on Merkle–Damgård hashes like SHA-256. The output is a fixed-size tag — 20 bytes for SHA-1, 32 for SHA-256, 64 for SHA-512 — usually transmitted as hex or Base64, which you can convert with the hex converter or Base64 tool if a provider hands you the other form.

How you'll use it. Paste the message and the shared secret to get HMAC-SHA1, HMAC-SHA256, and HMAC-SHA512. This is exactly how webhook providers sign payloads (for example an X-Signature header), how AWS Signature V4 derives its signing key, and how many API gateways authenticate requests. To verify an incoming webhook, recompute the HMAC over the raw body with your endpoint secret and compare it to the header. GitHub, Stripe, Slack, and Shopify all use this pattern — the header name and encoding differ, but the check is identical.

Common mistake. Comparing tags with an ordinary string equality (==) can leak timing information that helps an attacker recover the correct tag byte by byte. Always compare using a constant-time function such as crypto.timingSafeEqual. A second frequent bug is hashing a re-serialized JSON body instead of the exact raw bytes received — any whitespace difference produces a different digest and breaks the signature, so capture the body before any JSON parser touches it.

Defensive angle. Rotate HMAC secrets periodically, scope each integration to its own key, and reject requests whose timestamp is outside a small window to blunt replay attacks — a captured-and-replayed request still has a valid signature, so the timestamp check is what stops it. Prefer HMAC-SHA256 or stronger; HMAC-SHA1 is still cryptographically acceptable as a MAC but new designs should default to SHA-256. Generate secrets with real entropy from the password generator rather than typing a memorable string.