Can HMAC be used for password storage?

No. HMAC requires a shared secret key , which means you must store the key alongside the hashes — defeating the purpose of password hashing. Password storage algorithms like Bcrypt , Argon2 , and PBKDF2 are designed to be slow and memory-hard without requiring a separate key. HMAC is for message authentication (verifying data integrity and origin), not for storing credentials.

Is the HMAC tool free and private?

Yes. HMAC computation runs entirely in your browser — both your message and secret key stay local. The Web Crypto API performs the keyed hashing using native code, so your secret key never enters a network request. No input data is sent to any server.

HMAC Generator — Hash-based Message Authentication Codes

Hash or verify HMAC tags — with webhook signature presets for Stripe, GitHub, and Slack. Runs entirely in your browser.

Result

Message / Payload

Secret Key

Webhook preset

Algorithm

Your input never leaves your device; HMAC is computed locally using the Web Crypto API.

What is HMAC Generator?

HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function with a secret key to create a message authentication code. It verifies both the integrity and authenticity of a message. HMAC is the "H" in HS256 — sign and verify JWTs with our JWT tool.

Integrity + Authenticity — unlike a plain hash, HMAC proves the message hasn't been altered AND was created by someone who knows the secret key.

Standardized in RFC 2104 — used in TLS, JWT (HS256/HS512), IPsec, and many API authentication schemes.

Webhook signing — Stripe (t=…,v1=…), GitHub (sha256=…) and Slack (v0=…) all sign their webhook payloads with HMAC-SHA-256. This tool can build and verify those headers.

Keyed hash — the security depends on keeping the secret key private; the hash algorithm alone doesn't provide authenticity.

Parallel-safe — each (message, key) pair produces a unique tag; no chaining or state between computations.

Zero-Server Tool Data Guarantee

All computation happens locally in your browser using the Web Crypto API. Your message and secret key are never sent to any server.

How to Use

Enter Message

Type or paste the message (or webhook payload) you want to authenticate.

Enter Secret Key

Provide a secret key that is shared between the sender and receiver.

Select Algorithm or Preset

Choose SHA-256/SHA-512, or pick a Stripe, GitHub, or Slack preset to build the exact signature header those services expect.

Copy the HMAC

The HMAC is computed instantly. Use the copy button to save the hex string or the full webhook header.

Common Use Cases

API Request Signing

Sign each API request with HMAC so the server can verify it wasn't modified in transit and came from a trusted client.

Webhook Verification

Many services (Stripe, GitHub, Slack) send HMAC signatures with webhooks. Verify them to ensure requests are authentic.

JWT (HS256/HS512)

HMAC is the 'H' in HS256 — it's used to sign JWTs when you want symmetric (shared-secret) authentication.

Data Integrity

Append an HMAC tag to sensitive data (like cookies or URLs) and verify it before processing to detect tampering.

Implementation Examples

JavaScriptBrowser (Web Crypto API)

async function hmacSign(message, secret, algo = 'SHA-256') {
    const enc = new TextEncoder();
    const key = await crypto.subtle.importKey(
        'raw', enc.encode(secret),
        { name: 'HMAC', hash: algo }, false, ['sign']
    );
    const sig = await crypto.subtle.sign('HMAC', key, enc.encode(message));
    return Array.from(new Uint8Array(sig))
        .map(b => b.toString(16).padStart(2, '0')).join('');
}

const mac = await hmacSign('hello', 'my-secret-key');
// "c0e5d7337d0470a..."

HMAC vs Plain Hash vs Digital Signature

Feature	HMAC	Plain Hash (SHA-256)	Digital Signature (RSA/ECDSA)
Provides integrity?	Yes	Yes	Yes
Provides authenticity?	Yes (shared key)	No	Yes (public key)
Key type	Symmetric (shared)	None	Asymmetric (public/private)
Performance	Fast	Fastest	Slow (especially RSA)
Use case	API auth, webhooks	Checksums, dedup	Code signing, certificates
Non-repudiation?	No (both parties have key)	No	Yes

Production Best Practices & Security

Use HMAC-SHA-256 or HMAC-SHA-512 — avoid HMAC-SHA-1 for new designs, though it's still widely used in legacy systems. Why:SHA-256 and SHA-512 provide significantly higher security margins and are resistant to collision attacks (two different inputs producing the same hash) that affect older algorithms.

Keep the secret key truly secret — never hardcode keys in source code or client-side JavaScript; use environment variables or a secrets manager. Why:If an attacker finds your secret key, they can generate valid HMACs for any message, completely bypassing your integrity and authenticity checks.

Use a unique key per context — don't share the same HMAC key across different services or purposes. Why:Key reuse across different systems increases the risk; a compromise in one service would compromise all services sharing that key.

Verify HMAC on every request — don't skip verification even if you trust the network; network-level attacks can modify messages in transit. Why:Even within a "trusted" network, man-in-the-middle attacks can still occur. HMAC ensures that data remains authentic throughout its journey.

Use constant-time comparison — always compare HMACs with a timing-safe function to prevent timing side-channel attacks. Why:Standard string comparisons stop at the first differing character, allowing attackers to measure processing time and guess the HMAC character by character.

Rotate keys periodically — implement key rotation with a key ID to seamlessly switch between old and new keys. Why:Rotation limits the damage if a key is ever leaked, as the stolen key will only be valid for a limited window.

Frequently Asked Questions

HMAC (Hash-based Message Authentication Code) is a keyed-hash construct defined in RFC 2104 and FIPS 198-1. It uses a cryptographic hash function (like SHA-256) combined with a secret key to produce a fixed-length authentication tag.

Unlike a plain hash — which anyone can compute — HMAC ensures that only parties who possess the shared secret key can generate or verify the tag.

This makes HMAC essential for API authentication (where the server verifies requests come from an authorized client), JWT signatures (HS256), and any scenario requiring both message integrity and origin authenticity.

A regular SHA-256 hash provides integrity only — anyone who knows the message can recompute the hash and verify it hasn't changed.

HMAC provides both integrity and authenticity by incorporating a secret key into the hashing process using a specific construction (inner and outer key padding, double hashing). Without the key, an attacker cannot forge a valid HMAC for a modified message.

This is why HMAC is used in API signing, JWT tokens, and secure communications — it proves the message came from someone with the secret key, not just that it arrived intact.

HMAC-SHA256 is the recommended default for most modern applications. It provides 128-bit security, is hardware-accelerated via SHA-NI, and is universally supported.

HMAC-SHA512 offers a higher 256-bit security margin at a slight performance cost, useful for high-security scenarios or when the output will be used as a key (key derivation).

Avoid HMAC-SHA1 for new designs. While still widely deployed (including in older TLS versions and AWS Signature V2), its 80-bit collision resistance — how hard it is to find two different inputs that produce the same hash — is below modern standards.

Stripe sends the Stripe-Signature header in the form t=1723000000,v1=…. The signed string is {timestamp}.{payload} — the timestamp from the t= field, a literal dot, then the raw request body.

Select the Stripe preset, paste the raw body and your whsec_… webhook secret, then paste the full header into the verify box. The tool recomputes HMAC-SHA256(timestamp + "." + payload) and compares it with a constant-time comparison.

For production code, also check the timestamp is within ~5 minutes of the current time to protect against replay attacks, and compare against all vN values in the header in case of key rotation.

GitHub sends the X-Hub-Signature-256 header in the form sha256=…. The signature is HMAC-SHA256(payload) — the raw request body, with no timestamp or prefix.

Select the GitHub preset, paste the raw body and your webhook secret, then paste the full header (or just the sha256=… value) into the verify box. The tool recomputes the HMAC over the payload and compares it constant-time.

Use X-Hub-Signature-256 (SHA-256) rather than the older X-Hub-Signature (SHA-1) when you configure the webhook.

Slack sends the X-Slack-Signature header in the form v0=…. The signed string is v0:{timestamp}:{payload}, where the timestamp comes from the separate X-Slack-Request-Timestamp header.

Select the Slack preset, paste the raw body, the X-Slack-Request-Timestamp value into the timestamp field, and your signing secret into the secret field. Then paste v0=… into the verify box.

Slack computes HMAC-SHA256("v0:" + timestamp + ":" + payload) and compares it constant-time. In production, also reject requests whose timestamp differs by more than 5 minutes to prevent replay attacks.

When you compare two strings with a regular equality check (===, ==, or a normal equals), the comparison stops at the first differing character. The time it takes therefore leaks information about how many leading characters matched.

An attacker can measure this timing over many requests and recover the expected signature one character at a time — a classic timing side-channel attack. This tool always compares signatures with a constant-time algorithm that runs the same operations regardless of where the first difference appears.