Gera Tools

HMAC-SHA256 Generator

Compute keyed HMAC-SHA256 message authentication codes

Generate an HMAC-SHA256 authentication code from a secret key and message, with the key as UTF-8 text or hex bytes and output in hex and Base64. Computed locally with the Web Crypto API — nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is HMAC-SHA256?

HMAC-SHA256 is a keyed hash that combines a secret key with a message using SHA-256 to produce a 256-bit authentication tag. It proves both that the message is intact and that it came from someone holding the key.

HMAC-SHA256 is a keyed-hash message authentication code: it mixes a secret key with a message and the SHA-256 hash function to produce a 256-bit tag. Unlike a plain hash, the tag cannot be forged or recomputed without the key, which is why APIs and webhook providers use it to sign requests. This tool computes it locally using the browser’s Web Crypto API.

How it works

HMAC is defined (RFC 2104) as:

HMAC(K, m) = H( (K' XOR opad) || H( (K' XOR ipad) || m ) )

where H is SHA-256, K' is the key padded or hashed to the block size, ipad/opad are fixed padding constants, and || is concatenation. The double-hashing structure is what makes HMAC resistant to length-extension attacks that affect naive H(key || message) constructions.

This tool imports your key as raw bytes (interpreting it as UTF-8 text or hex), signs the message with crypto.subtle.sign, and renders the resulting 32-byte MAC as both lowercase hex (64 characters) and Base64.

Why HMAC instead of a plain hash

A plain SHA-256 hash of key + message is not secure for authentication:

  • Anyone who knows the message can compute SHA256(key || message) and produce a fake signature — they just need to guess the key.
  • More critically, SHA-256 is vulnerable to length-extension attacks: an attacker who knows SHA256(key || message) and the length of the key can compute SHA256(key || message || extra) without knowing the key. This means a naive hash(key + message) scheme can be exploited to forge signatures for extended messages.

HMAC’s double-hashing construction closes both of these weaknesses.

Verifying webhook signatures

Many providers sign webhook payloads with HMAC-SHA256. The general verification pattern is:

  1. Take the raw request body exactly as received (before parsing) — even a single whitespace or newline difference will change the result.
  2. Use the signing secret from your webhook dashboard as the key.
  3. Compute HMAC-SHA256 of the body with that key.
  4. Compare your computed value against the signature header the provider sends (usually in hex or Base64).

Common providers using HMAC-SHA256 webhook signatures include Stripe (Stripe-Signature header), GitHub (X-Hub-Signature-256), and many others. Use the lowercase hex output of this tool to compare against those headers.

Key format: text vs hex

  • UTF-8 text key: use when the signing secret is a human-readable string (letters, numbers, symbols). Most webhook dashboard secrets are in this form.
  • Hex key: use when the key is stored as raw bytes printed in hex, such as a 32-byte random key represented as 64 hex characters. Paste the hex string and switch the input mode to “hex” so it is decoded to bytes before use.

Using the wrong mode will produce a different HMAC even if the key value looks the same, since a hex key treated as UTF-8 text doubles the key length in bytes.

Security notes

  • The same key and message always produce the same tag; any single-byte change to either completely changes the output (the avalanche effect from SHA-256).
  • HMAC-SHA256 outputs a 32-byte (256-bit) tag. Truncating it reduces security; use the full length when possible.
  • Computation is local — your key and message never leave the browser.