Developer Tools· 4 min read

Generate HMAC-SHA-256/384/512 Signatures for Webhook Auth

You will learn how to compute keyed hash message authentication codes using SHA-256, SHA-384, and SHA-512 for webhook verification and API security.

By EasyDevTools Team Last updated: 2026-08-24

Why this matters

Hash-based Message Authentication Codes are the backbone of webhook integrity verification across every major SaaS platform. Stripe, GitHub, Slack, and Twilio all sign their outgoing webhook payloads with HMAC-SHA-256, and your server must recompute that exact signature to confirm the payload was not tampered with in transit. Without HMAC verification, any attacker who discovers your webhook URL can forge events and trigger unintended side effects in your application.

Unlike a plain hash, HMAC combines a cryptographic hash function with a secret key, producing a signature that is computationally infeasible to forge without knowing that key. The Web Crypto API powering this tool uses the same primitive that underpins TLS handshakes and JWT libraries, so the signatures you generate here match what production code produces. For developers debugging webhook integrations or building proof-of-concept auth flows, having a quick HMAC generator eliminates the need to write throwaway scripts.

See it in action

Supported algorithms at a glance

AlgorithmSignature lengthTypical use
HMAC-SHA-25664 hex charsWebhooks, JWT HS256
HMAC-SHA-38496 hex charsHigh-security environments
HMAC-SHA-512128 hex charsCompliance-driven systems

How to use it

Enter the exact message string you want to authenticate in the message field.

Paste your secret key into the key field, which is masked by default for visual safety.

Select the hash algorithm: SHA-256 for standard webhooks, SHA-384 or SHA-512 when compliance policies require longer digests.

Click Compute HMAC and copy the lowercase hex signature from the output area.

Compare the result against a known-good signature using a constant-time comparison function in your backend code.

Testing your result

The fastest way to validate your HMAC output is to cross-check against a known test vector. RFC 4231 defines official test cases for HMAC-SHA-256, SHA-384, and SHA-512 with a known key and message that produce deterministic signatures. If your output matches those test vectors exactly, you can trust the tool for production-adjacent debugging. You can also verify by computing the same HMAC in your backend language and comparing the hex strings character by character.

Common mistakes

Including or excluding a trailing newline in the message, which changes the digest entirely.

Using different encodings for the key (UTF-8 bytes versus a hex-decoded binary key).

Comparing signatures with a standard string equality operator instead of a constant-time function, which leaks timing information.

Assuming HMAC-MD5 or HMAC-SHA-1 are available here; the Web Crypto API excludes them because those hash functions are no longer collision-safe.

Edge cases and options

An empty message still produces a valid HMAC, which is useful when the signed payload consists only of headers or metadata concatenated elsewhere. An empty key is technically accepted by the API but produces a degenerate MAC that offers no security, so the tool should not be used that way for anything beyond curiosity. The secret field masks input visually, but the underlying `crypto.subtle.importKey` call treats the input as raw bytes, meaning multi-byte UTF-8 characters in the key will produce different signatures than their ASCII representation.

Real-world use cases

Verifying Stripe webhook signatures by computing HMAC-SHA-256 of the raw request body with your webhook signing secret.

Validating Slack request signatures that concatenate a version string, timestamp, and body before signing.

Generating signed tokens for stateless session cookies when you do not want the overhead of a full JWT library.

Building internal API authentication between microservices where shared-secret HMAC is simpler to deploy than public-key cryptography.

Frequently asked questions

Q: How is the HMAC computed?

A: The Web Crypto API's `crypto.subtle.importKey` imports the secret as a raw HMAC key with the chosen hash, then `crypto.subtle.sign` produces the signature. This is the same primitive used by TLS and JWT libraries.


Q: Which algorithms are supported?

A: HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. MD5 and SHA-1 are not exposed by the Web Crypto API because they are not collision-safe.


Q: Can I use this to verify webhook signatures?

A: Yes. Many webhook providers like Stripe, GitHub, and Slack sign payloads with HMAC-SHA-256. Compute the HMAC of the raw payload body with your webhook secret and compare.


Q: What format is the output?

A: Lowercase hexadecimal with no separators. The signature length matches the hash: 64 chars for SHA-256, 96 for SHA-384, 128 for SHA-512.


Q: Does the secret leave my machine?

A: No. All crypto operations run locally. Still, avoid pasting production secrets into any web tool; prefer a CLI for sensitive operations.


Q: Can I use a hex-encoded key instead of plain text?

A: The tool treats the key input as raw text. If your secret is hex-encoded, you would need to decode it to bytes first in your application code before computing the HMAC.

Start using it now

Try the HMAC Generator tool. See also Hash Generator and JWT Decoder and Base64 Encode / Decode.

Need help using this tool?

Read our complete HMAC Generator tutorial for step-by-step guidance.

Ready to try the tool?

No accounts. No uploads. No limits. Start now.