/

HMAC Generator

Processed Client Side

Generate HMAC authentication signatures with SHA-256, SHA-1, SHA-384, or SHA-512. Signs your message with a secret key using the browser's Web Crypto API.

Message & key
Secret key
Hash algorithm
Output
Message
Length: 0Lines: 1Size: 0 BytesCursor: 1:1
Signature
Enter a secret key and message, then click Generate.

Bookmark this tool now — skip the search next time you need it.

About HMAC Generator

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

Generate an HMAC signature for a message using a shared secret key. HMAC is what proves both that a message has not been altered and that it came from someone holding the secret — which is why it underpins webhook verification, API request signing, and the signature segment of a JWT. It differs from a plain hash in exactly that second property: anyone can hash a message, but only a holder of the key can produce a valid HMAC for it. Choose your hash algorithm and get the signature as hex or Base64, whichever the system you are integrating with expects. Because the same message and key always give the same signature, the tool doubles as a way to verify one: compute the value yourself and compare it against the header a webhook arrived with.

Key features

  • Four hash algorithms: SHA-256, SHA-384, SHA-512, and SHA-1
  • Output as hex or Base64, matching whichever encoding the receiving system expects
  • Computed with the browser native Web Crypto API
  • Separate fields for the secret and the message, so neither gets mangled
  • Correct UTF-8 handling, so signatures match what your backend computes
  • Errors surfaced clearly rather than producing a silently wrong signature
  • One-click copy of the signature
  • Hex and Base64 both encoded from the raw signature bytes, so neither is a conversion of the other and both are exact
  • Deterministic output, which is what makes it usable for verifying a signature as well as producing one
  • Runs entirely in your browser — your secret is never transmitted

How to use it

  1. Enter the shared secret.
  2. Paste the exact message bytes to be signed.
  3. Choose the hash algorithm and the output encoding the other system expects — both are read when you generate, so change them before signing rather than after.
  4. Generate, then compare or copy the signature.

Tips & common mistakes

  • SHA-256 is the default almost everywhere. Only pick SHA-1 when integrating with a legacy system that requires it — HMAC-SHA1 is not broken the way plain SHA-1 is, but there is no reason to choose it for new work.
  • The message must match byte for byte. A trailing newline, different line endings, or a re-serialized JSON body with reordered keys all produce a completely different signature.
  • Webhook verification is the most common use: recompute the HMAC over the exact raw request body and compare it with the header the sender provided. Use the raw body, never the parsed and re-stringified version.
  • Compare signatures with a constant-time comparison in production code. An ordinary string comparison leaks timing information that can be exploited.
  • Hex and Base64 encode the same bytes. If your signature never matches, check the encoding before you doubt the key.
  • HMAC proves integrity and authenticity, not confidentiality. The message itself is still readable by anyone who intercepts it.
  • Your secret stays in the browser here, but treat any secret pasted into any tool as worth rotating if it is a production key.
  • The key is used as raw bytes, so a secret written as a hex or Base64 string signs as that literal text, not as the bytes it decodes to. Backends differ on this, and it is the most common reason two correct implementations disagree.
  • Longer output is not stronger authentication here. HMAC-SHA256 has no practical weakness, and choosing SHA-512 only matters if the other side expects it.

Related tools

Browse all 8 Security tools

Frequently asked questions

10

HMAC verifies that a message came from someone holding a shared secret key and was not altered in transit. It is widely used to sign API requests and to verify webhook payloads from services like Stripe and GitHub.

A plain hash like SHA-256 only fingerprints data. HMAC mixes in a secret key, so only parties who know the key can produce or verify the signature — giving you authentication, not just integrity.

HMAC-SHA256 is the standard choice for most APIs and webhooks. SHA-384 and SHA-512 offer longer digests; SHA-1 is supported for legacy systems but should be avoided for new work.

Match whatever the service you are integrating with expects. Hex is common in documentation and URLs; Base64 is more compact and common in HTTP headers.

Yes. The message and secret never leave your device — signing uses the native Web Crypto API (crypto.subtle.sign) entirely client-side.

Almost always the message bytes. A trailing newline, different line endings, or a JSON body that was parsed and re-stringified with reordered keys all change the result completely.

Recompute the HMAC over the exact raw request body and compare it with the header the sender supplied. Use the raw body, never the parsed and re-serialized version.

With a constant-time comparison. An ordinary string comparison returns early on the first differing byte, which leaks timing information an attacker can exploit.

Not in the same way — the collision attacks on SHA-1 do not directly break HMAC-SHA1. There is still no reason to choose it for new work over SHA-256.

No. It proves integrity and authenticity only. The message itself remains readable to anyone who intercepts it — use encryption if you need confidentiality.