HMAC Generator
SecurityCompute HMAC message authentication codes using SHA-256, SHA-512, or MD5 with a custom secret key. Verify API signatures and authenticate messages online.
HMAC is computed entirely in your browser via the WebCrypto API — keys never leave your device.
Secret Key
Message
HMAC-SHA-256 Signature
HMAC signature will appear here
About HMAC Generator
The HMAC Generator computes Hash-based Message Authentication Codes using a shared secret key and your choice of underlying hash function — SHA-256 (recommended), SHA-512 (maximum hash strength), SHA-1 (legacy), or MD5 (compatibility only). HMAC simultaneously provides data integrity (the message has not been altered) and authenticity (the sender knows the secret key), making it the standard mechanism for signing API requests, validating webhook payloads (GitHub, Stripe, Twilio), and constructing JWT signatures. Computation runs in the browser via the Web Crypto API, so neither the message nor the secret key is transmitted to any server.
Features
- ✓Supports HMAC-SHA-256, HMAC-SHA-512, HMAC-SHA-384, HMAC-SHA-1, and HMAC-MD5
- ✓Secret key input supports plain text or hex-encoded binary keys
- ✓Output in lowercase hex, uppercase hex, and base64 for all common use cases
- ✓Verify mode: compare a computed HMAC against an expected value with constant-time equality
- ✓Message input accepts plain text with UTF-8 encoding (standard for most APIs)
- ✓One-click copy of each output format
- ✓Runs via the Web Crypto API (SubtleCrypto.sign) for browser-native performance
- ✓Shows byte length of the key and message as a debugging aid
- ✓100 % client-side — secret keys and messages never leave your browser
Common Use Cases
- Verifying a webhook signature from GitHub, Stripe, Twilio, or other services
- Generating the HMAC-SHA256 signature component for AWS Signature Version 4 request signing
- Debugging API authentication by computing and comparing HMAC values step by step
- Validating that a JWT HS256 or HS512 signature is correct for a given payload and secret
- Signing outgoing webhook payloads in a server application and verifying the signature client-side
- Testing HMAC library implementations in different languages against a known-correct reference value
- Computing HMAC-based one-time passwords (HOTP) as a building block for 2FA systems
- Authenticating data transfers in IoT or embedded systems during development and testing
Frequently Asked Questions
QWhat is the difference between a hash and an HMAC?
A plain cryptographic hash (e.g., SHA-256) produces a fixed-size digest of a message but provides no authentication — anyone can recompute it without knowing a secret. An HMAC mixes a secret key into the hash computation using a defined scheme (HMAC = hash(key ⊕ opad ∥ hash(key ⊕ ipad ∥ message))), so only parties that know the key can produce or verify the MAC. This makes HMAC suitable for message authentication where a hash alone is not.
QWhich HMAC algorithm should I use?
HMAC-SHA-256 is the best choice for most applications. It is mandated by many security standards (RFC 7519 for JWT HS256, AWS Signature V4) and provides 128 bits of security. HMAC-SHA-512 doubles the output size and is appropriate for very high-security contexts. Avoid HMAC-MD5 in new designs — while it has no known HMAC-specific breaks, MD5 is deprecated and may trigger security scanners.
QHow do I verify a GitHub webhook signature?
GitHub sends an `X-Hub-Signature-256` header containing `sha256=<hex_digest>`. In this tool, set the algorithm to HMAC-SHA-256, paste the raw request body as the message, enter your webhook secret as the key, and compare the hex output with the value after the `sha256=` prefix. A match confirms the payload is authentic.
QShould my secret key be a random string or a password?
For security, the HMAC key should be a cryptographically random binary string of at least 32 bytes (256 bits) for HMAC-SHA-256. Human-memorable passwords have low entropy and are vulnerable to brute-force attacks if an attacker intercepts HMAC values. Use a key generator or `crypto.getRandomValues()` to produce a suitable key.
QWhat is constant-time comparison and why does it matter for HMAC verification?
Standard string comparison short-circuits as soon as two bytes differ, which creates a timing side-channel that can reveal partial information about the expected HMAC value through careful timing measurements. Constant-time comparison always processes all bytes regardless of where a mismatch occurs, preventing this attack. The verify mode in this tool uses a constant-time comparison implementation.
QCan HMAC be used to sign JWTs?
Yes. The HS256, HS384, and HS512 JWT signature algorithms are HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 respectively. The signed data is `base64url(header) + '.' + base64url(payload)` and the secret is the shared symmetric key. Note that HS256 uses a symmetric key (same key to sign and verify), making it unsuitable for scenarios where issuers and verifiers should be different parties — use RS256 or ES256 (asymmetric) in those cases.