HMAC Generator — Message Authentication Codes

Secret key

Algorithm

Message

Share X / Twitter Facebook LinkedIn WhatsApp

How to use HMAC Generator

Enter the message and the secret key.
Choose the hash algorithm — HMAC-SHA256 is the standard.
Generate the signature — reproducible from the same message+key.
Verify by recomputing: match the sender's HMAC using constant-time comparison; keep the secret server-side only.

What is HMAC Generator?

An HMAC generator produces a Hash-based Message Authentication Code — a hash computed with a secret key, so it proves both that a message wasn't altered and that it came from someone who knows the key. HMAC-SHA256(message, secret) is the ubiquitous form: same message + same key = same signature; change either and it changes.

The key is what separates HMAC from a plain hash. Anyone can compute SHA-256 of a message; only holders of the shared secret can compute the correct HMAC — which is exactly why it authenticates. It answers "did this come from who I think, unchanged?" — the question plain hashes can't.

About the HMAC Generator

Enter your message and secret key, pick the hash (SHA-256 is standard), and generate the HMAC signature.

Where HMAC runs the internet's plumbing: webhook verification — Stripe, GitHub, Shopify and countless services sign webhook payloads with HMAC using a secret only you and they know; your endpoint recomputes the HMAC and compares, rejecting forged or tampered calls (the canonical use — verify every webhook this way); API request signing — AWS Signature, many API auth schemes HMAC the request so servers confirm it came from a real key-holder and wasn't modified in transit; token integrity — the signature in JWTs (HS256) is HMAC-SHA256; and secure cookies and CSRF tokens — HMAC prevents client-side tampering.

Two essentials: the secret must stay secret (leaking it lets anyone forge signatures — treat it like a password, server-side only), and verification should use constant-time comparison (comparing signatures with normal string-equals leaks timing information attackers can exploit — libraries provide safe compare functions). This generator is for testing and learning; production uses your language's crypto library. See our JWT Decoder for the token side and SHA-256 for the underlying hash.

Frequently Asked Questions

The secret key. Anyone can compute SHA-256(message); only key-holders can compute the correct HMAC(message, key). So a plain hash proves integrity; HMAC proves integrity AND authenticity — that it came from someone with the shared secret.

Recompute HMAC over the raw request body using the shared secret, compare (constant-time) against the signature the sender put in a header. Match = genuine and unaltered; mismatch = reject. It's the standard defense against forged webhooks.

Normal string comparison returns early on the first mismatched character, and the tiny timing difference leaks how much of the signature was correct — enough for attackers to forge it byte by byte. Crypto libraries provide constant-time compare (hash_equals, crypto.timingSafeEqual) for exactly this.

Anyone can forge valid signatures — total loss of the guarantee. Rotate the secret immediately, treat it like a password (environment variables, secret managers, never in client code or version control).

HMAC-SHA256 is the default standard — secure and universal. HMAC-SHA512 where longer output or a spec requires it. Avoid HMAC-MD5/SHA1 for new systems (the underlying hashes are weak, though HMAC construction is more forgiving than raw use).