HMAC Generator

HMAC stands for Hash-based Message Authentication Code. It is a cryptographic construction that takes two inputs — a secret key and a message — and produces a fixed-size signature that anyone who knows the same secret key can verify but no one without the key can forge. The original specification was published as RFC 2104 in 1996, and it has remained essentially unchanged since. HMAC is one of the most-deployed cryptographic primitives in production today; almost every webhook-driven API on the internet uses it for request signing.

Where you'll see HMAC in practice

Webhook signatures are the most-common use. When Stripe, GitHub, Shopify, Razorpay (the Indian payments giant), Xendit (the dominant Indonesian fintech infrastructure provider) or NETS (Singapore's domestic payment scheme) send a webhook to your server, they include an HMAC signature in the request headers. Your server independently computes the HMAC of the request body using the shared secret, then compares — if the signatures match, the request really came from the provider and wasn't tampered with in transit. AWS signature version 4 (used to sign every authenticated AWS API call) is HMAC-SHA256 under the hood. JSON Web Tokens signed with the HS256, HS384 or HS512 algorithm are HMAC underneath. Even older APIs like Twitter's OAuth 1.0a flow used HMAC-SHA1.

HMAC versus a plain hash

A common mistake is to "sign" a message by computing SHA256(secret + message) directly. This is not secure — it is vulnerable to a class of attacks called length-extension attacks, where an attacker who has seen one valid signature can compute valid signatures for longer messages without knowing the secret. HMAC's construction (which involves two nested hash operations with carefully-chosen XOR'd keys) is provably immune to length extension. The performance cost is roughly one extra hash operation; the security benefit is the difference between a sound construction and a broken one.

Constant-time verification

When you verify a webhook signature, do not compare strings directly with === or strcmp. Use a constant-time comparison function instead — hash_equals in PHP, crypto.timingSafeEqual in Node.js, hmac.compare_digest in Python. The reason is a timing attack: a naive string comparison returns false at the first byte that differs, leaking information about how many leading bytes were correct. A constant-time comparison takes the same time regardless of where the strings differ, denying that side-channel. This matters specifically for verification, not for the HMAC computation itself.

Picking the right output encoding

HMAC produces bytes. Bytes have to be encoded as text for transmission in HTTP headers or JSON bodies. The three common encodings are hex (twice as long as the raw bytes, lower-case alphanumeric only — used by GitHub, Stripe, AWS), base64 (about 33% longer than raw, includes +/= characters which sometimes need URL-encoding — used by Slack, Shopify), and base64url (same length as base64 but uses -_ instead of +/ and drops padding — used by JWTs). The right encoding depends on the destination; check the API provider's documentation. The tool above shows all three so you can match without re-running.

Common implementation mistakes

Three traps catch most teams the first time they implement HMAC verification. First, signing the wrong bytes — many webhook providers sign the raw request body, but a JSON-parsing middleware can re-serialise it before your handler runs, mangling whitespace and breaking the match. Always sign the original raw bytes. Second, leaking the secret in logs or error messages. Third, rotating the secret without a grace window that accepts both old and new for a few minutes.