HMAC Generator Online — SHA-1, SHA-256, SHA-384, SHA-512

Sign messages with HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 using a shared secret. Choose hex or Base64 output. Powered by the Web Crypto API — secrets never leave your browser.

AlgorithmOutputHex length: 64

Secret Key

Message

HMAC-SHA256 (hex)

Click Sign to compute the HMAC tag.

What is an HMAC?

An HMAC (Hash-based Message Authentication Code, RFC 2104) is a fixed-length tag computed from a message and a shared secret using a cryptographic hash. Anyone who holds the secret can verify the message was not modified and was sent by someone who knows the key. HMAC powers GitHub webhooks, Stripe webhooks, JWT HS256 tokens, AWS SigV4 signatures, Twilio request validation, and most REST API authentication you see in production.

This generator uses the browser native crypto.subtle.sign with HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 — the same primitives Node, Deno, Cloudflare Workers, and Bun expose. Choose hex output for webhook signature headers or Base64 for JWT-style encodings. Nothing leaves your browser; the secret stays on your machine.

How to generate an HMAC online — 4 steps

Paste the secret key. The same shared secret your server and webhook sender both hold. Treat it like a password — generate from a CSPRNG and store in a secrets manager.
Paste the message. The exact UTF-8 bytes to sign — a webhook JSON body, a JWT header.payload, an AWS canonical request, or a plain string.
Pick algorithm and format. HMAC-SHA256 + hex matches GitHub and Stripe; HMAC-SHA256 + Base64URL matches JWT HS256; HMAC-SHA1 + hex covers legacy systems.
Click Sign and copy. The signature appears in microseconds. Drop it into your X-Signature header, test fixture, or replay-proof comparison.

Sample input and output

Secret:    mysecretkey
Message:   {"event":"order.created","id":42,"amount":1999}
Algorithm: HMAC-SHA256
Output (hex):
  e7c5f4d2b1a8...  (64 hex chars)
Output (base64):
  58X00rGo...     (44 base64 chars)

Equivalent in Node:
  crypto.createHmac('sha256', 'mysecretkey')
    .update('{"event":"order.created","id":42,"amount":1999}')
    .digest('hex')

Equivalent in Python:
  hmac.new(b'mysecretkey',
    b'{"event":"order.created","id":42,"amount":1999}',
    hashlib.sha256).hexdigest()

Four Hash Algorithms

HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 — every variant the Web Crypto API supports, covering modern APIs and legacy interop.

Web Crypto Native

crypto.subtle.sign delegates to platform-optimised native code. Signing a kilobyte payload finishes in microseconds, even on mobile.

Secret Stays Local

Both the secret and the message are processed in your browser. Open DevTools — no network requests fire when you click Sign.

Common use cases

check_circleWebhook signing — generate the X-Signature-SHA256 header senders attach so receivers can verify the payload
check_circleJWT HS256 — sign the Base64URL header.payload to mint short-lived authentication tokens
check_circleAPI request authentication — HMAC the canonical request (method + path + body + timestamp) for replay-proof signed requests
check_circleAWS S3 presigned URL signature — produce the StringToSign HMAC for direct browser uploads to S3
check_circleGitHub webhook verification — recompute the X-Hub-Signature-256 to confirm a payload came from GitHub
check_circleStripe webhook verification — match the t= timestamp + payload HMAC against the Stripe-Signature header
check_circleTwilio request validation — HMAC-SHA1 the URL plus sorted form parameters before trusting an inbound request
check_circleTest fixtures — pre-compute deterministic signatures for unit tests so server code can be verified offline

HMAC vs hash vs digital signature

Property	Hash (SHA-256)	HMAC	Digital Signature (RSA / Ed25519)
Key required	None	Shared secret	Private key (asymmetric)
Verifier needs	Same input	Same secret	Public key
Detects tampering	Yes (if hash trusted)	Yes	Yes
Proves identity	No	Yes (to secret holders)	Yes (publicly)
Non-repudiation	No	No	Yes
Speed	Fastest	~2× hash	100–1000× slower

Use a plain hash for checksums and content addressing. Use HMAC when both sides share a secret (webhooks, internal API auth, JWT HS256). Use a digital signature when the verifier should not be able to forge new messages — public APIs, software updates, and SSH/TLS handshakes.

Need to verify an HMAC?

Pair the generator with the HMAC verifier and other crypto-secure tools — all browser-side.

HMAC Verify Hash Generator Password Generator UUID Generator

Frequently Asked Questions

What is HMAC?

HMAC (Hash-based Message Authentication Code, RFC 2104) combines a cryptographic hash function with a shared secret key to produce a fixed-length tag that authenticates a message. It guarantees both integrity (the message was not modified) and authenticity (it was signed by someone holding the secret). HMAC is the workhorse behind webhook signatures, JWT HS256 tokens, AWS SigV4 request signing, and millions of REST API authentication flows.

HMAC vs plain SHA-256 — what is the difference?

A bare SHA-256 of (key + message) is vulnerable to length-extension attacks: an attacker who knows H(key||msg) can compute H(key||msg||extra) without the key. HMAC defeats this with two nested hashes using inner and outer key pads (ipad/opad). Always use HMAC — never raw SHA-256(secret + payload) — when you need a keyed authentication tag.

Which algorithm should I pick?

HMAC-SHA256 is the default for new work — it matches GitHub webhooks, Stripe webhooks, AWS SigV4, and JWT HS256. HMAC-SHA512 gives extra collision margin and is faster than SHA-256 on 64-bit CPUs for long messages. Use HMAC-SHA1 only when interoperating with older systems (Twilio request validation, legacy AWS S3 signatures); SHA-1 collisions do not break HMAC-SHA1, but new code should still pick SHA-256.

How long should the secret key be?

RFC 2104 recommends a key at least as long as the hash output: 32 bytes for HMAC-SHA256, 64 bytes for HMAC-SHA512. Keys longer than the hash block (64 bytes for SHA-1/256, 128 for SHA-384/512) are pre-hashed; shorter keys are zero-padded — both work, but a key shorter than the digest reduces effective security. Generate keys from a CSPRNG (crypto.getRandomValues) and store them in a secrets manager, never in source.

Hex or Base64 — which output format?

Hex is the convention for X-Hub-Signature-256 (GitHub webhooks), Stripe-Signature, and most webhook headers. Base64 is shorter and used by JWT HS256 (Base64URL specifically), AWS SigV4 headers, and HTTP Basic-style schemes. Hex is twice as long as Base64 for the same digest but is case-insensitive and easier to compare visually.

Is the secret sent to your servers?

No. HMAC computation runs entirely in your browser using the Web Crypto SubtleCrypto API. Open DevTools → Network and click Sign — no requests are made. The secret never touches our servers, our logs, or any third-party analytics.

Can I generate the same HMAC in Node, Python, and curl?

Yes — HMAC is a deterministic standard. Node: crypto.createHmac("sha256", secret).update(msg).digest("hex"). Python: hmac.new(secret.encode(), msg.encode(), hashlib.sha256).hexdigest(). OpenSSL CLI: echo -n "msg" | openssl dgst -sha256 -hmac "secret". All three produce the same hex string this tool produces — handy for verifying server code matches your test vector.

What about HMAC for JWT tokens?

JWT HS256 is HMAC-SHA256 over the Base64URL-encoded header and payload joined by a dot, then the result Base64URL-encoded (no padding). To sign a JWT here, set message to "header.payload" (each part already Base64URL-encoded), pick HMAC-SHA256, choose Base64 output, and convert "+" to "-", "/" to "_", and strip "=" padding to get Base64URL. For end-to-end JWT work, use a dedicated library that handles canonical encoding.