HMAC Generator
Compute HMAC values from exact UTF-8 messages, selectable key encodings, and SHA-2 algorithms.
The browser textarea value is encoded as UTF-8. Spaces, punctuation, and JSON property order are preserved. Browser textarea line breaks are represented as LF, so raw CRLF or binary webhook bodies should be verified with their exact bytes.
HMAC Value
Computed HMAC will appear here.
Browser-local computation
HMAC is computed with the Web Crypto API in your browser. The message, key, and result are not sent to Yoryantra. Local extensions, clipboard software, device monitoring, and malware remain outside that guarantee.
Matching an API requires the exact signing recipe
Many services call an HMAC a “signature,” but HMAC is a shared-key message authentication code, not a public-key digital signature. A mismatch can come from different message bytes, canonicalization, timestamp prefixes, key decoding, algorithm choice, or output encoding.
HMAC authenticates bytes, not what the text looks like
HMAC combines a secret key with a hash function so someone holding the same key can recompute the MAC for the same message. A changed byte produces a different result. HMAC does not encrypt the message, and it does not prove which individual person created it when more than one system knows the shared key.
That byte-level view explains many failed webhook tests. A trailing newline, CRLF instead of LF, a reordered JSON object, or a decoded key treated as literal Base64 text all change the input to HMAC.
Key encoding is part of the protocol
UTF-8 text
Characters are encoded to UTF-8 bytes. Spaces and Unicode are meaningful parts of the key.
Hex bytes
Every two hex digits become one byte. Odd-length or non-hex input is rejected instead of guessed.
Base64 bytes
Standard Base64 is decoded first. Whitespace is ignored, while impossible lengths and non-canonical pad bits are rejected.
Hex, Base64 and Base64URL are only representations
Changing the output encoding does not change the underlying HMAC bytes. Hex uses two characters per byte. Base64 is denser and may contain +, /, and padding. Base64URL swaps those two alphabet characters and this page removes trailing padding, which is common in token-oriented formats.
Reading RFC 2104 in a modern SHA-2 workflow
RFC 2104 defines HMAC as a generic construction around an iterated hash function. It also discusses key length: very short keys reduce security strength, while keys longer than the hash block size are first hashed by the HMAC construction. In an API integration, the service's documented key format still takes precedence over any generic rule of thumb.
References: RFC 2104 · Web Crypto HMAC signing
A reliable mismatch checklist
- Compare the exact raw message body before parsing or reformatting it.
- Confirm whether the service signs a prefix, timestamp, path, method, or body combination.
- Decode the secret using the format the service specifies.
- Use the required SHA-2 variant.
- Encode the result exactly as the receiver expects before comparing.
- For verification code, compare MACs with the platform's constant-time facility where available.