HMAC Generator

A plain hash proves nothing about who produced it, because anyone can hash the same text. HMAC mixes a secret key into the hash, so a matching digest proves the sender knew the key. That is why webhooks are signed with HMAC and not with a bare SHA-256.

Almost always because the message is not byte identical. The most common cause is signing a re-serialized JSON object instead of the raw request body. Whitespace, key order and a trailing newline all change the digest. Some providers also sign a timestamp and the body joined with a separator, so check their documentation for the exact string.

Whatever the other side uses. Stripe and GitHub send hex, AWS and many older SOAP style APIs use Base64. They are two encodings of the same bytes, so if the hex matches after conversion, the signature is valid.

HMAC-SHA1 has not been broken the way plain SHA-1 collisions were, and TOTP still uses it. Even so, there is no reason to choose it for something new. Use SHA-256 unless you are talking to a system that only speaks SHA-1.

No. The digest is computed by the Web Crypto API inside this tab. There is no upload, no logging and no analytics on the values you type.

At least as long as the hash output, so 32 bytes for SHA-256. Shorter keys are padded internally and add no security. Generate one with our API key generator rather than picking a memorable phrase.

Yes. Verification is just generating the HMAC yourself and comparing it with the one you received. In your own code, compare with a timing safe function such as crypto.timingSafeEqual rather than a plain equality check.

Yes. Both the key and the message are encoded as UTF-8 before hashing, so ş, ğ, ı and the rest produce the same digest they would in any correct implementation.