How to use the HMAC Generator
Generate an HMAC signature in four steps:
1
Select the algorithm
Choose HMAC-SHA256 (recommended for most uses), HMAC-SHA384, HMAC-SHA512 (maximum strength), or HMAC-SHA1 (legacy only). Algorithms marked with ✓ are recommended.
2
Enter the secret key
Type your secret key or click 'Random' to generate a cryptographically secure 256-bit random key. The key strength meter shows whether your key meets length recommendations.
3
Enter the message
Paste the message to authenticate — this can be a JSON payload, URL, HTTP request body, or any string.
4
Copy the HMAC signature
The HMAC signature is computed instantly. Choose hex or Base64 output format depending on your system's requirements.
When to use this tool
Use HMAC whenever you need to authenticate and verify the integrity of a message:
- →Verifying GitHub, Stripe, Twilio, or Shopify webhook signatures by computing HMAC-SHA256 of the request body with the shared secret
- →Generating and verifying JWT tokens signed with HMAC-SHA256 (HS256), HMAC-SHA384 (HS384), or HMAC-SHA512 (HS512)
- →Signing AWS API requests using AWS Signature Version 4 which uses HMAC-SHA256 for each signing step
- →Building API authentication systems where clients must sign requests with a shared secret key
- →Debugging HMAC mismatch errors by computing the expected signature locally and comparing with what your server generates
- →Generating secure tokens for password reset links, email verification, and one-time access URLs
Frequently asked questions
Q:What is the difference between HMAC and a regular hash?
A regular hash like SHA-256(message) provides integrity (you can detect changes) but not authenticity — anyone can hash any message. HMAC(key, message) provides both integrity AND authenticity because it requires knowledge of the secret key to produce or verify the signature. An attacker who intercepts HMAC(key, message) cannot forge a valid HMAC for a modified message without knowing the key. HMAC also prevents length extension attacks that affect raw SHA-256/SHA-512 when used as MACs. Use HMAC whenever you need to prove that a message came from someone who holds the secret key.
Q:How long should my HMAC secret key be?
HMAC keys should be at least as long as the hash output: 32 bytes (256 bits) for HMAC-SHA256, 48 bytes for HMAC-SHA384, and 64 bytes for HMAC-SHA512. NIST SP 800-107 recommends keys of at least the hash output length. Keys longer than the block size (64 bytes for SHA-256/SHA-1, 128 bytes for SHA-384/512) are pre-hashed by HMAC, so there's no benefit to keys beyond the block size. Short keys (under 16 chars) are vulnerable to brute-force. Click 'Random' in this tool to generate a cryptographically secure 64-character (256-bit) hex key using crypto.getRandomValues().
Q:How do I verify a GitHub webhook HMAC-SHA256 signature?
GitHub sends an X-Hub-Signature-256 header with the value sha256=<hmac>. To verify: (1) extract the raw request body as bytes (before any JSON parsing), (2) compute HMAC-SHA256 of the raw body using your webhook secret as the key, (3) compare the hex output (prefixed with 'sha256=') to the header value using a constant-time comparison function. This tool lets you manually verify by pasting the request body as the message and your webhook secret as the key — compare the hex output to the header value (without the 'sha256=' prefix). The same pattern applies to Stripe (Stripe-Signature header) and most other webhook platforms.
Q:What is HMAC-SHA256 used for in AWS Signature Version 4?
AWS Signature Version 4 uses HMAC-SHA256 in a multi-step key derivation and signing process: (1) HMAC-SHA256("AWS4" + secret_key, date) produces a date key; (2) HMAC-SHA256(date_key, region) produces a region key; (3) HMAC-SHA256(region_key, service) produces a service key; (4) HMAC-SHA256(service_key, "aws4_request") produces a signing key; (5) finally, HMAC-SHA256(signing_key, string_to_sign) produces the request signature. This derived key approach ensures that signatures are scoped to a specific date, region, and service, limiting the impact of key exposure. This tool can help debug individual HMAC steps in the chain.
Q:Why does HMAC-SHA1 remain secure even though SHA-1 is broken?
SHA-1's weakness is its collision resistance — it's feasible to find two different inputs that hash to the same value. HMAC's security, however, depends on the hash function's pseudo-random function (PRF) properties and second pre-image resistance, not collision resistance. An attacker forging an HMAC must find a message that produces a specific HMAC output for an unknown key — which requires either pre-image attacks (finding an input that hashes to a given output) or key recovery, neither of which are feasible against SHA-1. HMAC-SHA1 has no known practical attacks. That said, HMAC-SHA256 provides a larger security margin and is universally preferred for new implementations.
Q:Is it safe to use this browser-based tool with real secret keys?
This tool computes HMAC entirely in your browser using the Web Crypto API — no data is sent to any server. The computation is local and ephemeral. However, best practices for handling production secrets still apply: (1) avoid using actual production keys in any web-based tool when possible; (2) use this tool for testing, debugging, and learning with dummy keys; (3) for production key operations, use server-side code or a CLI tool like openssl (openssl dgst -sha256 -hmac 'key' -out hmac.bin message.txt). The random key generator uses crypto.getRandomValues(), which is cryptographically secure, so generated keys are safe to use.