Why not just hash the key and the message together?

Because that construction is vulnerable to a length extension attack on the SHA-2 family: someone who knows the digest can append to the message and produce a valid signature without knowing the key. HMAC uses the key twice in a specific structure that closes it. It is the difference between a signature and something that looks like one.

Is my key sent anywhere?

No, and that is the reason this page exists. The keys people paste into an HMAC tool are live webhook secrets and API signing keys. Every hosted version receives a copy of each one, which is the single worst thing you can leak. This runs in the page and you can verify that by disconnecting from the network.

Why does the signature not match the one I was sent?

Almost always because the message bytes differ. A trailing newline, a re-serialised JSON payload with different key order or spacing, or a different character encoding all change the result completely. Sign the raw body exactly as it arrived, not a parsed and re-printed version of it.

HMAC Generator

Keyed signatures, without sending the key.

Message

Key

Algorithm

Format

HexBase64Colon separated

Keyed signatures, without sending the key.

How to use it

Paste the message. The exact bytes that were signed, including any whitespace.
Enter the key. It stays in the page. Nothing is transmitted.
Compare the signature. Against the one in the header you are checking.

When you would use this

An HMAC is how a webhook proves it came from who it says it did, and debugging one means computing the signature yourself and comparing. The reason to do that here rather than on the first search result is the key. An HMAC tool asks you for the shared secret, and that secret is the entire security of the integration. Every hosted version of this tool receives a copy of every key pasted into it. This one runs in the page: there is no server, so there is nothing to receive it. On the construction itself: HMAC is not simply hashing the key and the message together. That naive version is vulnerable to length extension on the SHA-2 family, where someone holding a valid digest can append data and produce a valid signature without ever knowing the key. HMAC applies the key twice in a specific structure that closes it, and the tests here check the output against OpenSSL rather than against itself. If your signature does not match, it is nearly always the message bytes rather than the algorithm. A trailing newline or a re-serialised JSON body changes the result completely.

Questions

Why not just hash the key and the message together?: Because that construction is vulnerable to a length extension attack on the SHA-2 family: someone who knows the digest can append to the message and produce a valid signature without knowing the key. HMAC uses the key twice in a specific structure that closes it. It is the difference between a signature and something that looks like one.
Is my key sent anywhere?: No, and that is the reason this page exists. The keys people paste into an HMAC tool are live webhook secrets and API signing keys. Every hosted version receives a copy of each one, which is the single worst thing you can leak. This runs in the page and you can verify that by disconnecting from the network.
Why does the signature not match the one I was sent?: Almost always because the message bytes differ. A trailing newline, a re-serialised JSON payload with different key order or spacing, or a different character encoding all change the result completely. Sign the raw body exactly as it arrived, not a parsed and re-printed version of it.