About the HMAC Generator
An HMAC is a keyed hash: combining a shared secret with the message produces a code that proves both integrity (the message wasn't altered) and authenticity (the sender knew the secret). This tool computes HMAC-SHA256 and HMAC-SHA512 locally in your browser — the standard mechanism behind webhook signatures, API request signing, and JWT HS256 tokens.
The most common practical use is webhook verification: GitHub's X-Hub-Signature-256, Stripe's Stripe-Signature, and Slack's signing secret all work the same way — compute the HMAC of the raw request body with your secret and compare it to the header value.
Frequently asked questions
Why use HMAC instead of just hashing the message with the secret appended?
Plain hash(secret + message) is vulnerable to length-extension attacks on Merkle–Damgård hashes like SHA-256 — an attacker can append data and compute a valid hash without knowing the secret. HMAC's nested construction (two passes with derived keys) closes this, which is why it is the standard despite seeming redundant.
Why doesn't my webhook signature match the provider's?
Almost always a body mismatch: you must HMAC the exact raw bytes received — before JSON parsing, re-serialization, or any middleware that re-encodes whitespace or unicode. Other classics: hex vs Base64 output encoding, including/excluding the sha256= prefix, and comparing with == instead of a constant-time comparison.
SHA-256 or SHA-512 for HMAC?
Both are secure; HMAC-SHA256 is the de facto interoperability standard and what most providers expect. HMAC-SHA512 offers a larger tag and is marginally faster on 64-bit CPUs, but the practical driver is matching whatever the other side of the integration specifies.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.