Why not just hash the key and the message together?

H(key ‖ message) is vulnerable to length-extension attacks on Merkle–Damgård hashes: an attacker can append data and compute a valid digest without the key. HMAC's nested construction with two padding constants prevents this.

Which algorithm should I choose?

HMAC-SHA256 unless a counterparty requires otherwise. HMAC-SHA1 remains cryptographically acceptable for MAC use but is being retired; prefer SHA-256 for anything new.

Why does my webhook signature never match?

Almost always because you signed a re-serialized body rather than the raw bytes, or because a proxy altered the payload. Capture the exact body before any middleware parses it.

No. It authenticates a message you can still read. To hide the contents you need encryption, ideally an AEAD mode that provides both.

Security🌐 YAS server-sideAPI availableintermediate

HMAC Generator

Computes an HMAC — a keyed message authentication code — with SHA-1/256/384/512.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Message

Secret key

Loading tool…

What does this tool do?

Computes an HMAC — a keyed message authentication code — with SHA-1/256/384/512.

Why would I use it?

You are signing an API webhook or request with a shared secret.
You want to verify a message was not tampered with (integrity + auth).
You are implementing a signing scheme.

Real-life example

Input

message: "hello", key: "secret", algo: HMAC-SHA256

Output

88aab3ede8d3adf94d26e90b5b1c4e2e...

The same message with a different key produces a different HMAC.

Input → Process → Output → Next

Input: Enter message, key and algorithm.
Process: YAS computes the keyed digest.
Output: HMAC in hex and Base64.
Next action: Send it in a header like X-Signature and verify on the receiver.

Common mistakes

Using a weak shared key.
Transmitting the secret alongside the message.
Confusing HMAC with plain hashing (HMAC is keyed).

What the result means

A valid HMAC proves the message came from someone with the key.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/hmac-generator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/hmac-generator" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello","key":"secret","algorithm":"sha256"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/hmac-generator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "message": "hello",
  "key": "secret",
  "algorithm": "sha256"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/hmac-generator", json={"message":"hello","key":"secret","algorithm":"sha256"})
data = r.json()

Field	Type	Required	Description
message	string	Yes	Message
key	string	Yes	Secret key
algorithm	string	No (default sha256)	sha1 \| sha256 \| sha384 \| sha512

Success response

{ "algorithm": "sha256", "hex": "2cf24dba5fb0a30e...", "base64": "LPI..." }

Compute HMAC-SHA1/256/384/512 for a message and key.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How HMAC Generator works

HMAC combines a secret key with a hash function in a specific nested construction defined in RFC 2104: H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ message)). The two distinct padding constants and the double hashing are what make it a proper message authentication code. Naively prefixing a key to a message and hashing it — H(K ‖ m) — is vulnerable to length-extension attacks against Merkle–Damgård hashes such as SHA-256, which HMAC is specifically designed to prevent.

The output proves two things at once: the message was not modified, and it was produced by someone holding the key. That is authentication, not encryption — the message itself remains readable. Keys shorter than the hash block size are zero-padded and longer keys are hashed down, so key length beyond the digest size adds no security.

When to use it: real-world scenarios

Verifying an inbound webhook signature

Stripe, GitHub and Shopify sign payloads with HMAC-SHA256 over the raw request body. Computing the expected value here shows whether a mismatch is a wrong secret or a body your framework already re-serialized.

Signing API requests

AWS SigV4 and similar schemes derive a signing key through chained HMACs. Reproducing one step at a time is the fastest way to find where your implementation diverges.

Creating tamper-evident tokens

An unsubscribe or password-reset link can carry a payload plus an HMAC, letting the server detect any modification without a database lookup.

Pseudonymising identifiers

HMAC with a server-held key turns an email address into a stable pseudonym that cannot be reversed by dictionary attack, unlike a plain hash.

Pro tips

Sign the raw request body bytes, exactly as received. Parsing JSON and re-serializing changes whitespace and key order, which changes the signature — the single most common webhook verification bug.
Compare signatures with a constant-time function. A byte-by-byte early-exit comparison leaks the correct prefix through timing.
Include a timestamp in the signed payload and reject old messages, otherwise a valid signature can be replayed indefinitely.
Use a key of at least the digest length from a random source. HMAC keys are secrets, not passwords, and should never be human-chosen.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

HMAC provides integrity and authenticity, not confidentiality. The message is not hidden.
Both parties share the same key, so an HMAC cannot prove which of them produced a message — use a digital signature for non-repudiation.
Anyone with the key can forge valid values, which makes key distribution the hard part of any HMAC deployment.
This runs server-side through the API, so do not send production signing keys to it; compute those in your own environment.

Frequently asked questions

Why not just hash the key and the message together?: H(key ‖ message) is vulnerable to length-extension attacks on Merkle–Damgård hashes: an attacker can append data and compute a valid digest without the key. HMAC's nested construction with two padding constants prevents this.
Which algorithm should I choose?: HMAC-SHA256 unless a counterparty requires otherwise. HMAC-SHA1 remains cryptographically acceptable for MAC use but is being retired; prefer SHA-256 for anything new.
Why does my webhook signature never match?: Almost always because you signed a re-serialized body rather than the raw bytes, or because a proxy altered the payload. Capture the exact body before any middleware parses it.
Is HMAC encryption?: No. It authenticates a message you can still read. To hide the contents you need encryption, ideally an AEAD mode that provides both.

Related tools

Hash Calculator JWT Encode / Sign