HMAC Generator - HMAC Encrypt

HMAC Generator - Generate Message Authentication Codes Online

HMAC (Hash-based Message Authentication Code) is the cryptographic primitive that powers virtually every API authentication scheme in production: AWS Signature v4, Stripe webhook signatures, GitHub Actions secrets, Slack request verification, Twilio request signing, Mailgun event callbacks, every JWT with an HS256/HS384/HS512 alg, and the entire OAuth 2.0 MAC token spec all reduce to HMAC at their core. Standardised in RFC 2104 (Krawczyk, Bellare, Canetti, 1997) and proven secure under standard assumptions on the underlying hash, HMAC takes two inputs — a shared secret KEY and a MESSAGE — and produces a fixed-size signature that anyone with the key can re-derive and compare. This is fundamentally different from a plain hash like sha256(message): without the key, an attacker can compute their own sha256 of any tampered message and replace yours; with HMAC, they cannot forge a matching signature without knowing the key. This generator runs the full WebCrypto implementation client-side and supports all three SHA-2 family variants (SHA-256 for most modern uses, SHA-512 for high-security applications, SHA-1 for legacy systems that you should be migrating away from), with both hexadecimal output (the universal text-safe format for headers and config files) and base64 (the standard for JWT signatures and many auth APIs). Never reuse a secret across services, never embed it in client-side code, and rotate it periodically. See also our SHA-512 Hash Generator and MD5 Hash Generator.

What is HMAC?

HMAC (Hash-based Message Authentication Code) is a cryptographic algorithm that combines a hash function with a secret key to create a message authentication code.

Key features:
- Verifies both data integrity and authenticity
- Requires secret key (shared between sender/receiver)
- Based on standard hash functions (SHA-256, SHA-512, etc.)
- Used in APIs, JWTs, webhooks, and secure communications

HMAC = Hash(secret_key + message)

Example:
Message: "Hello, World!"
Secret: "mySecretKey"
HMAC-SHA256: a4e624d686e03ed2767c0abd85c14426b0b1157d2ce81d27bb4fe4bc1e4fa3a6

How do I generate an HMAC?

1. Enter your message/data
2. Enter your secret key
3. Select hash algorithm (SHA-256 recommended)
4. Choose output format (hex or base64)
5. Click 'Generate HMAC'
6. Copy the HMAC code

Example:
Message: "user=john&action=login"
Key: "api_secret_key_123"
Algorithm: HMAC-SHA256
Output: 64-character hex string

The same message + key will always produce the same HMAC.

What is HMAC used for?

HMAC is widely used for secure authentication and integrity verification:

✓ API Authentication:
- AWS signature verification
- GitHub webhooks
- API request signing
- OAuth signatures

✓ JWT (JSON Web Tokens):
- HS256, HS384, HS512 algorithms
- Token signature verification

✓ Message Integrity:
- Webhook payload verification
- Data tampering detection
- Secure message transmission

✓ Session Management:
- Cookie signing
- CSRF token generation
- Session validation

HMAC ensures both authenticity (sender has the key) and integrity (message unchanged).

Which HMAC algorithm should I use?

Choose based on your security needs:

HMAC-SHA256 (Recommended):
✓ Industry standard
✓ Fast and secure
✓ 64-character hex output
✓ Used by most APIs
✓ JWT HS256

HMAC-SHA512 (More Secure):
✓ Maximum security
✓ 128-character hex output
✓ Better for high-value data
✓ JWT HS512

HMAC-SHA1 (Legacy):
⚠️ Deprecated for new projects
✓ Only for legacy compatibility
✓ 40-character hex output

For most applications: Use HMAC-SHA256
For maximum security: Use HMAC-SHA512
Avoid SHA-1 for new projects.

How does HMAC verify messages?

HMAC verification process:

1. Sender:
- Creates message
- Generates HMAC with secret key
- Sends message + HMAC

2. Receiver:
- Receives message + HMAC
- Generates HMAC from message using same key
- Compares generated HMAC with received HMAC
- Match = authentic, no tampering
- Mismatch = reject (tampered or wrong key)

Example:
Message: "transfer $100"
Key: "shared_secret"
HMAC: abc123...

If attacker changes to "transfer $1000":
- New HMAC won't match
- Receiver rejects the message

HMAC protects against tampering and ensures sender authenticity.

How do I verify a Stripe / GitHub / Slack webhook signature using HMAC?

All three follow the same pattern with different details. The webhook provider POSTs a JSON payload to your endpoint along with a header containing an HMAC signature of that exact payload, computed using a shared secret you configured during webhook setup. Your job: recompute the HMAC on the body you received and compare with the header value using a CONSTANT-TIME comparison (==, ===, strcmp leak timing info; use crypto.timingSafeEqual in Node or hmac.compare_digest in Python). If they match, the request really came from the provider and was not tampered with in transit; if they don't, reject with 401. (1) Stripe: header 'Stripe-Signature: t=1234567890,v1=abc...', secret starts with 'whsec_', algorithm HMAC-SHA256, signed payload is timestamp + '.' + body. (2) GitHub: header 'X-Hub-Signature-256: sha256=abc...', secret you set per-repo, HMAC-SHA256 of raw body. (3) Slack: header 'X-Slack-Signature: v0=abc...', signing secret from app config, HMAC-SHA256 of 'v0:' + timestamp + ':' + body. Always also reject if the timestamp is more than 5 minutes old to prevent replay attacks.

Why does my HMAC computed in Python not match the one from Node.js?

Eight out of ten times it's an encoding mismatch — you're hashing different byte sequences without realising it. Run through this checklist. (1) Key encoding: in JavaScript 'Buffer.from(secret)' assumes UTF-8 by default but '.from(secret, 'hex')' interprets the same string as hex bytes. If your secret looks like '00ff42' it might be a 3-byte hex value OR a 6-byte UTF-8 string of '00ff42'. (2) Message encoding: same issue. JSON serialisation must produce the exact same bytes on both sides — even key order differences ({a:1,b:2} vs {b:2,a:1}) produce different signatures. Most APIs require you to sign the raw JSON byte sequence the client sent, not a re-serialised version. (3) Output encoding: hex vs base64 vs URL-safe base64 differ. (4) Newlines: \n on Linux/Mac but \r\n in the request body from a Windows-based client; HMAC sees them as different bytes. (5) Whitespace: trailing spaces in the message. Solution: print the exact bytes (Buffer.from(...).toString('hex')) on both sides for a known small test message until they match, then move to the real payload.

Can I use HMAC for passwords?

NO! HMAC is NOT for password hashing.

HMAC:
✓ Message authentication
✓ API signatures
✓ Data integrity
✗ NOT password storage

For passwords, use:
✓ bcrypt (recommended)
✓ Argon2 (modern)
✓ PBKDF2 (acceptable)

Why?
- HMAC is fast (not good for passwords)
- HMAC needs a key (passwords are the secret)
- HMAC doesn't use salt properly for passwords

HMAC and password hashing serve different purposes!

Key Features

• Generate HMAC from any message instantly
• Support for SHA-256, SHA-512, and SHA-1
• Hexadecimal or Base64 output format
• Secret key with show/hide toggle
• Web Crypto API for secure hashing
• Copy HMAC to clipboard
• Download HMAC as text file
• Algorithm and output info display
• Dark mode support
• 100% client-side processing
• Works offline
• No registration required