HMAC Generator
Sign messages with HMAC-SHA-1/256/512. Key + message, hex output.
HMACSignClient-sideFree to use
Algorithm
Output
How to use
- Pick algorithm. SHA-1, SHA-256, or SHA-512.
- Enter key and message. Both UTF-8 text.
- Copy the HMAC. Hex-encoded digest.
Common use cases
- Signing webhooks
- API request authentication
- Verifying message integrity
Frequently asked questions
- What is HMAC used for in practice?
- HMAC is most commonly used to sign webhook payloads and API requests. A server sends a request body along with an HMAC of that body using a shared secret, and the receiver recomputes the HMAC to confirm the message has not been tampered with and came from a party that holds the key.
- Which algorithm should I choose: SHA-1, SHA-256, or SHA-512?
- SHA-256 is the standard choice for new integrations. SHA-1 is supported by some older APIs (such as early GitHub webhooks) but is considered weak for standalone hashing; in an HMAC context it remains safe, though SHA-256 is preferred. SHA-512 produces a longer digest and is appropriate when the receiving system requires it.
- How is HMAC different from a plain SHA hash?
- A plain hash takes only the message as input, so anyone can compute the same hash. HMAC mixes a secret key into the computation, meaning only parties that hold the key can produce a valid signature. This makes it suitable for authentication, not just integrity checking.
- Does this tool send my key or message to a server?
- No. All signing runs entirely in the browser via the Web Crypto API. Your key and message never leave your device.
- Why should I use constant-time comparison when verifying HMACs?
- A naive string equality check returns early as soon as it finds a mismatch, which leaks timing information an attacker can exploit to forge a valid signature one byte at a time. Libraries like Node's crypto.timingSafeEqual or Python's hmac.compare_digest compare all bytes in fixed time regardless of where a difference occurs.
Related tools
How to use
- Pick algorithm. SHA-1, SHA-256, or SHA-512.
- Enter key and message. Both UTF-8 text.
- Copy the HMAC. Hex-encoded digest.
Common use cases
- Signing webhooks
- API request authentication
- Verifying message integrity
Frequently asked questions
- What is HMAC used for in practice?
- HMAC is most commonly used to sign webhook payloads and API requests. A server sends a request body along with an HMAC of that body using a shared secret, and the receiver recomputes the HMAC to confirm the message has not been tampered with and came from a party that holds the key.
- Which algorithm should I choose: SHA-1, SHA-256, or SHA-512?
- SHA-256 is the standard choice for new integrations. SHA-1 is supported by some older APIs (such as early GitHub webhooks) but is considered weak for standalone hashing; in an HMAC context it remains safe, though SHA-256 is preferred. SHA-512 produces a longer digest and is appropriate when the receiving system requires it.
- How is HMAC different from a plain SHA hash?
- A plain hash takes only the message as input, so anyone can compute the same hash. HMAC mixes a secret key into the computation, meaning only parties that hold the key can produce a valid signature. This makes it suitable for authentication, not just integrity checking.
- Does this tool send my key or message to a server?
- No. All signing runs entirely in the browser via the Web Crypto API. Your key and message never leave your device.
- Why should I use constant-time comparison when verifying HMACs?
- A naive string equality check returns early as soon as it finds a mismatch, which leaks timing information an attacker can exploit to forge a valid signature one byte at a time. Libraries like Node's crypto.timingSafeEqual or Python's hmac.compare_digest compare all bytes in fixed time regardless of where a difference occurs.