HMAC Generator & Verifier
Generate and verify HMAC signatures with real-time payload verification. Supports MD5, SHA1, SHA256, SHA512, multiple input/key encodings, custom output formatting, and interactive backend integration code snippets.
Generate and verify HMAC signatures with real-time payload verification. Supports MD5, SHA1, SHA256, SHA512, multiple input/key encodings, custom output formatting, and interactive backend integration code snippets.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
HMAC — Hash-based Message Authentication Code — is a construction that combines a cryptographic hash function (SHA-256, SHA-512, SHA-1, MD5) with a secret key to produce a message authentication code. The fundamental difference from a plain hash is the key. SHA-256("hello") always produces the same value regardless of who computes it — anyone who has the message can verify or forge the hash. HMAC-SHA256("hello", secret_key) produces a value that can only be computed and verified by someone who knows the secret_key. The same message with a different key produces a completely different HMAC. This property — that the HMAC is unpredictable without the key — is what makes HMAC suitable for authentication, not just data integrity.
The HMAC construction was designed to prevent a class of attack called a length extension attack that affects plain SHA-256 and SHA-512 when used naively for message authentication. If you compute SHA-256(key + message) without the HMAC construction, an attacker who knows the hash value can compute SHA-256(key + message + additional_data) without knowing the key — they can extend the message. HMAC prevents this by computing hash(key XOR opad + hash(key XOR ipad + message)) — the double-hash structure with inner and outer padding makes length extension attacks impossible. This is why you should always use HMAC for keyed message authentication rather than computing SHA-256(key + message) yourself.
HMAC-SHA256 is the standard for most modern authentication contexts. OAuth 1.0a and OAuth 2.0 PKCE use HMAC-SHA256 for request signing. AWS Signature Version 4 uses HMAC-SHA256 in a chain of HMAC operations to derive a signing key. Webhook signature verification (GitHub, Stripe, Twilio, Shopify) uses HMAC-SHA256 to sign the request payload and send the signature as a header — the receiver recomputes the HMAC and compares it to the header value. HMAC-SHA1 is used by older systems including some OAuth 1.0 implementations and legacy webhook providers. HMAC-MD5 appears in some legacy protocols and systems but MD5's known weaknesses mean HMAC-MD5 should not be used for new implementations.
Enter a message body and a secret key, select the algorithm (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, or HMAC-MD5), and click Compute Signature. The tool computes the HMAC using the browser's native Web Crypto API (SubtleCrypto.sign() with the HMAC algorithm) and returns the signature as a lowercase hexadecimal string. The result matches exactly what your application's HMAC library produces for the same inputs: crypto.createHmac('sha256', key).update(message).digest('hex') in Node.js, hmac.new(key, message, hashlib.sha256).hexdigest() in Python, or HmacUtils.hmacHex(HmacAlgorithms.HMAC_SHA_256, key, message) in Java. The message field accepts any text content — a JSON request body, a plain string, a raw HTTP request body that you are trying to sign manually, or any other data the HMAC should be computed over. The secret key field accepts any string — the shared secret that only authorized parties know. Both inputs are treated as UTF-8 strings and encoded as bytes before the HMAC operation. If your application encodes the key differently (base64-decoded bytes, raw binary from an environment variable), you may need to handle the encoding externally and paste the correct text representation. The output is a fixed-length hex string: 64 characters for HMAC-SHA256, 128 characters for HMAC-SHA512, 40 characters for HMAC-SHA1, and 32 characters for HMAC-MD5. All computation runs in your browser — your message content and secret key are never transmitted to any server. This is the critical guarantee for this tool specifically: a cloud-based HMAC generator that processes your secret key on the server has permanently compromised that key, because the service operator now has it. Browser-only computation means the key stays with you.
1. Enter the message body in the Message Body field — this is the data the HMAC is computed over. For webhook debugging, this is the raw request body exactly as received from the provider (the JSON string, not the parsed object). For API request signing, this is the string your application builds before signing. Be precise: a single extra space, a different character encoding, or a trimmed newline will produce a completely different HMAC.
2. Enter the secret key in the Secret Auth Key field — this is the shared secret used to generate and verify the HMAC. For webhooks, this is the webhook signing secret from the provider's dashboard (GitHub webhook secret, Stripe webhook signing secret, etc.). For custom APIs, this is the pre-shared key. Keep this field value out of screenshots and avoid pasting production keys into browser tools you do not control. This tool runs entirely in your browser, but good habits matter.
3. Select the algorithm from the Security Algorithm dropdown — choose HMAC-SHA256 for modern systems and webhook providers (this is the standard), HMAC-SHA512 for systems requiring a larger signature, HMAC-SHA1 for legacy systems and older webhook implementations, HMAC-MD5 only when required by a legacy system with no alternative. Most providers specify which algorithm they use in their documentation — GitHub and Stripe use HMAC-SHA256, some older OAuth 1.0 systems use HMAC-SHA1.
4. Click Compute Signature — the HMAC is generated instantly using your browser's native Web Crypto API. The SHA256 Signature panel shows the hex-encoded result. Compare this to the expected signature from the provider or your test fixture. If they match, your inputs are correct. If they differ, check the message body for invisible differences (try copying both to a hex inspector), verify the key is correct, and confirm you are using the same algorithm.
5. Copy the signature using the Copy button and use it for comparison, testing, or documentation — paste it into your debugging notes, into your test fixture as the expected value, or into an API testing tool as the signature to verify against. For webhook debugging: if the computed signature matches the header value from the provider, your webhook secret and message body are correct. If not, the difference is in one of those three inputs.
Webhook signature verification debugging is the most common reason a developer needs to manually generate an HMAC. The pattern is standardized: a provider (GitHub, Stripe, Twilio, Shopify, Slack) sends a webhook POST request, includes an HMAC-SHA256 signature of the request body in a request header (X-Hub-Signature-256, Stripe-Signature, X-Twilio-Signature), and your application is supposed to recompute the HMAC from the request body and your webhook secret, then compare the two. When the comparison fails — which it always seems to do the first time — you need to manually reproduce what the provider computed to find where the mismatch is. Are you using the right secret? Is the message body the raw bytes or a parsed string? Is there a prefix in the header you are not stripping? This tool lets you compute the expected HMAC manually so you can compare step by step. AWS Signature Version 4 is another context where manual HMAC generation is genuinely useful. AWS SigV4 signs HTTP requests by running a chain of HMAC operations: HMAC("AWS4" + secret_key, date) to derive a date key, then HMAC(date_key, region) to derive a region key, then HMAC(region_key, service), then HMAC(service_key, "aws4_request") to derive the final signing key. Debugging a SigV4 implementation means stepping through each HMAC operation and verifying the intermediate values. This tool generates the HMAC at each step so you can verify the chain is being computed correctly. For developers implementing HMAC-based authentication in their own APIs — a shared secret for a mobile app or partner service to authenticate requests — being able to compute test HMACs manually is essential for writing integration tests and debugging. You know the expected signature for a given message and key, and you can verify your implementation produces the same value. The API consumer can use this tool to generate the expected HMAC for a test request and confirm their client implementation is correct before going to production.
Uses the browser's native Web Crypto API — HMAC computation uses SubtleCrypto.sign() the same cryptographic implementation browsers use for TLS and Web Authentication not a JavaScript reimplementation
Matches your application's library output — produces the same hex signature as Node.js crypto.createHmac Python hmac.new Java HmacUtils and any other standard HMAC implementation for the same inputs
Multiple algorithms — HMAC-SHA256 HMAC-SHA512 HMAC-SHA1 and HMAC-MD5 in a single tool covering all major HMAC variants used in modern and legacy systems
100% browser-based — your secret key and message content never leave your browser making this safe for webhook secrets API keys and production credentials
Copy button — the signature hex string can be copied in one click for use in test fixtures debugging notes or comparison verification
Supports all message types — any text content works as the message body including JSON strings raw HTTP bodies plain text and any other string content
Output length by algorithm — 64 hex chars for SHA256 128 for SHA512 40 for SHA1 32 for MD5 making it easy to confirm the algorithm matches the expected signature length
No installation required — generate HMAC signatures immediately without installing any tools or libraries
Debugging webhook signature verification failures for GitHub Stripe Twilio Shopify or Slack webhook integrations
Manually computing intermediate HMAC values when debugging AWS Signature Version 4 request signing implementations
Verifying that an HMAC implementation in application code produces the correct output for a known message and key
Testing OAuth 1.0 request signing implementations by generating the expected HMAC-SHA1 signature for a known request
Creating test fixtures with known HMAC signatures for use in unit tests of authentication middleware
Comparing HMAC values from different programming languages to verify consistent output across implementations
Debugging API gateway signature validation failures by reproducing the expected signature computation step by step
Learning the difference between HMAC algorithms by seeing how the output changes for the same message and key
Example Input
Message: The quick brown fox jumps over the lazy dog Secret Key: my-webhook-secret-key-2026 Algorithm: HMAC-SHA256
Example Output
SHA256 Signature: affee3b4888c714d8369e419b5e51d1ff7c024b64a94d76b8dd53c8fb5d8a2dc
Output length: 64 hex characters (256 bits)
Algorithm: HMAC-SHA256
Verification in Node.js:
const crypto = require('crypto');
const expected = crypto.createHmac('sha256', 'my-webhook-secret-key-2026')
.update('The quick brown fox jumps over the lazy dog')
.digest('hex');
// expected === 'affee3b4888c714d8369e419b5e51d1ff7c024b64a94d76b8dd53c8fb5d8a2dc'Missing Key: HMAC requires a non-empty secret key. An empty key field will either produce an error or generate an HMAC with an empty key, which is cryptographically meaningless — an HMAC computed with an empty key provides no authentication guarantee because any party can compute it. Ensure the Secret Auth Key field contains the actual secret before computing the signature.
Algorithm Mismatch — Both Parties Must Use the Same Algorithm: If your application expects an HMAC-SHA256 signature but you compute HMAC-SHA1 in the tool (or vice versa), the signatures will be completely different even with the correct message and key. HMAC-SHA256 produces a 64-character hex output and HMAC-SHA1 produces a 40-character hex output. If the signature you are comparing to has a different length than the tool's output, you are using the wrong algorithm. Check the webhook provider's documentation or API specification to confirm which algorithm they use before comparing signatures.
Empty Message: HMAC requires at least some content in the message field. An empty message produces a defined HMAC output (HMAC of an empty string with the key) but is rarely what you actually want. For webhook debugging, ensure you have pasted the actual request body content. For API signing, ensure the message string has been populated before computing.
Message Body Is Not the Raw Request Body: For webhook signature verification, the HMAC is computed over the exact raw bytes of the HTTP request body — not a parsed and re-serialized JSON object. If you parse the webhook body as JSON and then re-serialize it before computing the HMAC, the whitespace and key ordering may differ from the original, producing a different HMAC. Always use the raw body string as received, before any parsing. In Express.js, use req.rawBody or the raw-body middleware to access the unmodified body bytes.
Key Encoding Differences — Base64 Key vs Raw String: Some webhook providers and API systems provide the secret key as a base64-encoded string. If the HMAC computation expects the raw binary key (the base64-decoded bytes) rather than the base64 string itself, computing HMAC with the base64 string as the key will produce a different result. Stripe webhook secrets starting with whsec_ are base64-encoded and must be base64-decoded before use as the HMAC key. If your signature does not match even with the correct message body, check whether the key needs to be base64-decoded first.
Comparing HMAC signatures with regular string equality instead of constant-time comparison
Fix: A timing attack exploits the fact that string equality operators return early as soon as a mismatch is found — comparing 'abc' to 'xyz' returns false after checking the first character, while comparing 'abc' to 'abd' returns false after checking the third. An attacker who can observe response times can infer how many characters of their guessed signature match the real signature, iteratively narrowing down the correct HMAC byte by byte. For this reason, HMAC signature comparison in authentication code must always use constant-time comparison: crypto.timingSafeEqual() in Node.js, hmac.compare_digest() in Python, or MessageDigest.isEqual() equivalent. The HMAC generation in this tool is for testing and debugging. In your application code, never use === or .equals() to compare HMAC signatures — use the language's constant-time comparison function.
Using the same HMAC secret key for multiple different purposes
Fix: A secret key used for webhook signature verification should not be the same key used for session tokens, API authentication, or any other HMAC-based authentication in your system. Key separation is a fundamental security principle. If the webhook signing key is compromised, only the webhook verification is affected — not your session tokens and not your API authentication. Use separate keys for each distinct authentication purpose. Key management becomes more complex with multiple keys, but the blast radius of a compromised key is dramatically reduced.
Assuming HMAC prevents replay attacks
Fix: HMAC verifies that a message came from someone with the secret key and has not been modified. It does not prevent replay attacks — an attacker who intercepts a valid signed request can resubmit it later and it will pass HMAC verification because the signature is still valid. Webhook providers address this by including a timestamp in the signed payload and requiring the receiver to reject requests where the timestamp is more than a few minutes old (Stripe requires the request to be within 300 seconds, GitHub's does not expire but suggests checking the delivery ID). If you implement HMAC-based authentication for your own API, include a timestamp or nonce in the signed data and validate it on the receiving end.
Treating HMAC as encryption — thinking the message is hidden because it is signed
Fix: HMAC is an authentication mechanism, not an encryption mechanism. The message itself travels in plaintext — HMAC proves the message came from someone with the key and has not been modified, but anyone who intercepts the message can read its content. Webhook payloads from Stripe, GitHub, or any other provider are sent with HMAC signatures but the body is plain JSON — anyone with network access to the connection can read the payload. For confidentiality, use TLS (HTTPS) which encrypts the request in transit. HMAC over HTTPS provides both authenticity (who sent it and was it modified) and confidentiality (who can read it). HMAC without TLS provides authenticity but not confidentiality.
Not validating the timestamp in webhook HMAC verification
Fix: Most webhook providers include a timestamp in the signed payload specifically to prevent replay attacks. Stripe includes a t=timestamp field in the Stripe-Signature header and expects you to validate that the timestamp is within 300 seconds of the current time. GitHub includes the delivery ID which can be used to detect and ignore duplicate deliveries. If your webhook handler verifies the HMAC signature but does not check the timestamp, a valid signed webhook can be captured and replayed minutes, hours, or days later and your handler will accept it. After verifying the HMAC matches, always validate the timestamp: reject any webhook payload where the signed timestamp is more than 5 minutes old.
JWT
Syntaxes and patterns for JSON Web Tokens: structure (Header.Payload.Signature), signing keys, validation, claims (sub, exp, iat), and storage.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Why use HMAC instead of a simple hash?
A plain hash like SHA-256 provides data integrity — anyone can compute the hash of a message and verify it has not been modified. But anyone can also forge the hash by computing SHA-256 of a modified message. HMAC adds a secret key to the computation, making the signature unforgeable without the key. SHA-256(message) can be reproduced by anyone. HMAC-SHA256(message, secret) can only be reproduced by someone who knows secret. This is the difference between integrity (detecting modification) and authentication (verifying who produced the signature). Use HMAC when you need to verify both that a message was not modified AND that it came from someone who knows the shared secret.
Is it safe to share the secret key?
No. The security of HMAC depends entirely on the secrecy of the key. Anyone who has the key can produce valid HMAC signatures for any message — they can forge requests, impersonate senders, and bypass any HMAC-based authentication. Treat HMAC keys the same way you treat passwords and API keys: never share them in plain text, never commit them to source control, never include them in client-side code that users can inspect, and rotate them immediately if they are compromised. For webhook keys specifically, regenerate the webhook signing secret in the provider's dashboard if you suspect the key has been exposed.
Is it safe for sensitive API keys?
Yes — this tool runs entirely in your browser using the Web Crypto API. Your secret key and message content are never transmitted to any server. This matters specifically for HMAC debugging: if you use an online HMAC tool that sends your inputs to a server to compute the result, you have exposed your secret key to that service. This tool computes the HMAC locally in your browser tab. After you close the tab, the key is gone. For production webhook secrets and API signing keys, browser-local computation is the only acceptable approach for a public debugging tool.
How do I implement HMAC verification in my application?
In Node.js: const crypto = require('crypto'); const signature = crypto.createHmac('sha256', secretKey).update(messageBody).digest('hex'); const isValid = crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(receivedSignature)). In Python: import hmac, hashlib; signature = hmac.new(secret.encode(), message.encode(), hashlib.sha256).hexdigest(); is_valid = hmac.compare_digest(signature, received_signature). In Go: mac := hmac.New(sha256.New, []byte(secretKey)); mac.Write([]byte(message)); signature := hex.EncodeToString(mac.Sum(nil)); isValid := hmac.Equal([]byte(signature), []byte(receivedSignature)). Always use the constant-time comparison function (timingSafeEqual, compare_digest, hmac.Equal) — never regular string equality.
Why does my webhook HMAC verification fail even though the key seems correct?
Webhook HMAC failures almost always come from one of three sources. First, using the parsed request body instead of the raw bytes — your framework may parse and normalize the JSON before your handler sees it, changing the whitespace or key ordering. Use the raw body middleware and compute HMAC over the unmodified byte stream. Second, key encoding — some providers (Stripe with whsec_ prefix) base64-encode the secret, and you must base64-decode it before use. Third, header format — providers often include a prefix in the signature header (Stripe's Stripe-Signature is t=timestamp,v1=signature, not just the signature) and you need to parse out the actual signature part. Use this tool to compute the HMAC of the exact raw body with the exact key and compare step by step.
What algorithm does each major webhook provider use?
GitHub uses HMAC-SHA256 and includes the signature in the X-Hub-Signature-256 header with a sha256= prefix. Stripe uses HMAC-SHA256 and includes it in Stripe-Signature as v1=signature with a timestamp. Twilio uses HMAC-SHA1 (note: SHA1, not SHA256) and includes the signature in X-Twilio-Signature. Shopify uses HMAC-SHA256 in the X-Shopify-Hmac-Sha256 header. Slack uses HMAC-SHA256 in the X-Slack-Signature header with v0= prefix. Always check the provider's webhook documentation for the current algorithm — some providers have moved from SHA1 to SHA256 over time.
What is the difference between HMAC-SHA256 and HMAC-SHA512?
Both are HMAC constructions using SHA-2 family algorithms. HMAC-SHA256 produces a 256-bit (64 hex character) output. HMAC-SHA512 produces a 512-bit (128 hex character) output. Both are considered secure against any known attack. HMAC-SHA256 is the standard choice for new implementations and is what all major webhook providers use. HMAC-SHA512 provides a larger security margin and is sometimes used in high-security contexts or when the system requires a longer signature. For webhook verification and API authentication, HMAC-SHA256 is correct for virtually all use cases. Use HMAC-SHA512 only when a system specifically requires it.
Can HMAC be used for password storage?
No, and this is a common misconception worth addressing directly. HMAC is a fast operation — modern hardware can compute billions of HMAC-SHA256 operations per second. For password storage, you need a slow function specifically designed to resist brute force: bcrypt, Argon2id, or PBKDF2 with a high iteration count. These algorithms are designed to be computationally expensive even for short inputs. HMAC over a password would be brute-forceable almost as fast as a plain hash. HMAC is for authentication of messages and requests — proving a communication came from someone with the key. For passwords, use bcrypt or Argon2id, full stop.
How to Secure a Spring Boot Application in 10 Minutes: The 2026 Developer Security Checklist
A Spring Boot app can look production-ready and still expose dangerous defaults — from open actuator endpoints and weak JWT filters to hardcoded secrets, vulnerable dependencies, and unsafe SQL queries. This practical developer checklist walks through the exact 10-minute security checks you should run before deployment.
SQL Injection in Spring Boot (2026): Real Vulnerabilities, Prevention & Testing
Learn how SQL injection still breaks Spring Boot apps in 2026 with real Java vulnerabilities, blind SQLi examples, prevention checklists, and practical testing payloads.
Mastering API Security: How to Implement OAuth2 and JWT Without Common Vulnerabilities (2026)
Learn how to implement OAuth2 and JWT securely in 2026. Covers PKCE, token replay attack prevention, code examples in Python and Node.js, a full comparison table, and a developer checklist.
Recent Activity
No recent activity