# HMAC Generator

- **URL:** https://codeasystem.com/calculators/developer/hmac-generator/
- **Category:** developer
- **Description:** Compute keyed HMAC-SHA-256/384/512 signatures for API requests and webhook verification using native WebCrypto.
- **Primary output:** HMAC-SHA-256: b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7

## Inputs
- Message (name: `message`, type: textarea, example: request body or payload to sign)
- Secret key (name: `secret`, type: text, example: shared secret)
- Algorithm (name: `algorithm`, type: select)

## Outputs
- HMAC-SHA-256: b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7
- Key length: 20 UTF-8 bytes
- Message length: 8 UTF-8 bytes
- Verification: the recipient recomputes this exact hex given the same key and message

## Formula / methodology
```
HMAC(K,m) = H((K⊕opad) ∥ H((K⊕ipad) ∥ m)); RFC 2104
```

The secret imports as a raw WebCrypto HMAC key for your chosen hash; the UTF-8 message bytes are then signed in one call and rendered as lowercase hex. The construction internally hashes with inner and outer key-padded passes per RFC 2104.

Both parties holding the key can recompute the identical digest, which is exactly how GitHub, Stripe and Shopify webhook verification works; compare computed signatures byte-for-byte using constant-time equality.

## Assumptions & limitations
- Secret and message treated as UTF-8 text.
- Signatures shown for education; paste real production secrets only into trusted environments.
- Key reuse across messages is fine; key reuse across systems is not.

## How to use
1. **Paste the message**; The exact request body or payload you intend to sign or verify.
2. **Enter the shared secret**; Same key on both sides; that is the entire security model.
3. **Compare signatures**; Verification means recomputing locally and matching the sender’s header value exactly.

## Example
RFC 4231’s first test vector (key of twenty 0x0b bytes over the message “Hi There”) reproduces b0344c61…2e32cff7 exactly under HMAC-SHA-256.

Result for these inputs:

```
HMAC-SHA-256: b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7
```

## About this calculator
### Why HMAC instead of plain hashing

A bare SHA digest lets anyone forge a matching pair of message-plus-hash. HMAC binds a secret into the construction, so only key holders can produce valid signatures; the foundation of webhook auth, JWT HS256 tokens and session CSRF tokens alike.

### Verification hygiene

- Use constant-time comparison to dodge timing attacks
- Sign the raw body bytes before any parsing/reformatting
- Include a timestamp claim and reject stale messages
- Rotate keys without reusing them across environments

## FAQs
### Is my secret safe here?

Computation runs locally via WebCrypto. Still, treat anything pasted into a browser as potentially exposed; use test secrets here and keep production secrets in server-side tooling.

### HMAC-SHA-256 vs HMAC-SHA-512; which?

Both remain unbroken. SHA-512 often performs better on 64-bit servers; 256-bit output suits constrained headers. Consistency between endpoints matters more than the choice itself.

### Why does my signature mismatch the provider’s?

Almost always input drift: pretty-printed JSON, reordered fields or a trailing newline change the bytes. Sign the exact raw body.

### Can I use this for passwords?

No; HMAC is fast, which attackers love. Password storage needs slow, salted KDFs like bcrypt or argon2.

## Related calculators
- [SHA Hash Generator](https://codeasystem.com/calculators/developer/hash-generator/)
- [JWT Decoder](https://codeasystem.com/calculators/developer/jwt-decoder/)
- [Secure Password Generator](https://codeasystem.com/calculators/developer/password-generator/)

---
Last updated: 2026-08-23 · Version: 1.0.0 · [HTML version](https://codeasystem.com/calculators/developer/hmac-generator/)