HMAC Generator & Verifier

Generate and verify HMAC signatures using the browser's native Web Crypto API. Supports SHA-256, SHA-384, SHA-512, and SHA-1 with hex and base64 output — 100% browser-based, zero uploads.

HMAC Generator & Verifier
Generate and verify HMAC signatures using Web Crypto API. SHA-256, SHA-384, SHA-512 — entirely in your browser.
Result
Quick Reference
HMAC = Hash(key + message) — keyed hash for authentication
SHA-256 — most common, used in JWT HS256, API signing
SHA-512 — longer output, higher security margin
SHA-1 — legacy only, avoid for new implementations

How ZeroData protects your privacy

  • No Uploads: Tool input is processed in your browser and is not sent to ZeroData servers.
  • No Storage: Tool input is not saved by this website.
  • No Input Tracking: Analytics never receive the text, files, keys, or credentials you process.
  • Verifiable: Disconnect from the network after the page loads; local tool processing continues without uploading your input.

Quick Solution

To generate an HMAC-SHA256 signature in Node.js, use the native crypto module: const crypto = require('crypto'); const hmac = crypto.createHmac('sha256', 'your_secret_key').update('your_message').digest('hex');. This is the standard way to verify webhook payloads.

When Should I Use This?

Use an HMAC generator to verify cryptographic signatures or test webhook signature validation logic.

  • Testing the signature validation logic for Stripe, GitHub, or Twilio webhooks in your local development environment.
  • Generating secure API tokens for server-to-server communication using a shared secret.
  • Verifying the integrity of JWT (JSON Web Tokens) payload data using the HS256 algorithm.

Deep Dive: Cryptographic Mechanics of HMAC & Timing Attack Prevention

Hash-based Message Authentication Code (HMAC), specified in RFC 2104 and FIPS 198-1, is a symmetric cryptographic construction designed to simultaneously verify both the data integrity and the authenticity of a message using a shared secret key. Unlike plain cryptographic hash functions (SHA-256, SHA-512), which produce deterministic digests from input strings alone, HMAC combines the message payload with a confidential key through a rigorous double-hashing algorithm that resists length-extension vulnerabilities.

The mathematical definition of HMAC executes two distinct hashing passes over inner and outer padded key blocks:

HMAC(K, M) = H( (K ⊕ opad) || H( (K ⊕ ipad) || M ) )

In this formula, H represents the underlying cryptographic hash function (SHA-256 or SHA-512), K is the secret key padded or hashed to match the block size of the hashing algorithm, M is the message payload, and opad/ipad are fixed outer and inner padding constants (0x5c and 0x36 repeated). This nested structure prevents an adversary who intercepts the output digest from appending additional data bytes to the original message without possessing the secret key.

Preventing Timing Attacks in Production Verification: When verifying HMAC signatures (such as validating webhook payloads from Stripe, GitHub, or Shopify), a critical engineering pitfall is using standard string equality operators (like == in Python or === in JavaScript) to compare the computed digest against the received header digest. Standard equality checks return false the exact millisecond a character mismatch is detected, allowing attackers to measure microscopic timing variations across network requests and crack your HMAC secret character by character.

Always use constant-time comparison functions—such as crypto.timingSafeEqual() in Node.js, hmac.compare_digest() in Python, or subtle.verify() in the Web Crypto API—to guarantee that signature checks execute in uniform duration regardless of where a character mismatch occurs.

Troubleshooting HMAC Validation Errors

If your API or webhook is constantly rejecting valid payloads, verify these common engineering mistakes:

  • String Encoding Mismatches: HMAC relies heavily on exact byte representations. If your client encodes the payload in UTF-8 but the server parses it as ASCII or UTF-16 before hashing, the signatures will fundamentally mismatch.
  • JSON Formatting Drift: When verifying webhooks (like Stripe), you must hash the exact raw HTTP request body string. If your web framework parses the JSON into an object and then re-stringifies it, the spacing or key ordering might change, completely breaking the HMAC signature.
  • Base64 vs Base64URL vs Hex: Ensure both the client and server are outputting the exact same encoding. A common mistake in JWTs is using standard Base64 instead of Base64URL (which replaces + and / and removes padding =).

Security Best Practices for API Signing

  • Include Timestamps (Prevent Replays): HMAC only proves authenticity, not freshness. Always include a timestamp in the signed payload and reject requests older than 5 minutes to prevent replay attacks.
  • Use Constant-Time Comparison: Never use == or === to compare the received signature against your computed signature, as this exposes you to timing attacks. Use cryptographic constant-time equality functions.
  • Protect the Secret Key: The security of HMAC is entirely dependent on the secrecy of the shared key. Never hardcode keys in client-side applications (like React or mobile apps) unless it is a uniquely generated per-user session key.

Command Line (CLI) Alternatives

You can quickly generate HMAC signatures directly from your terminal using OpenSSL, which is incredibly useful for testing API endpoints via curl:

# Generate an HMAC-SHA256 signature and output as Hex
echo -n "my-api-payload" | openssl dgst -sha256 -hmac "my-super-secret-key"

# Generate an HMAC-SHA512 signature and output as Base64
echo -n "my-api-payload" | openssl dgst -sha512 -hmac "my-super-secret-key" -binary | base64

HMAC vs Hashing: Understanding When to Use Each

Regular cryptographic hash functions like standard SHA-256 are exceptional at verifying data integrity — confirming that a file or string hasn't been tampered with or corrupted during transit. However, they fundamentally fail to prove authenticity because any user on the internet can compute the exact same hash for a given file. HMAC (Hash-based Message Authentication Code) elegantly solves this profound limitation by mathematically incorporating a secret cryptographic key directly into the hash computation process. Because of this, only trusted parties who possess the exact shared key can generate or verify the resulting HMAC, simultaneously proving both that the data is perfectly intact and that it originated from a highly trusted source.

If you simply need to generate plain file or string hashes without a secret key, use our Hash Generator for computing SHA-256, SHA-512, and MD5 checksums. For verifying and troubleshooting secure bcrypt password hashes, try our specialized Bcrypt Hash Verifier.

HMAC in JWT and API Request Signing

HMAC-SHA256 serves as the foundational cryptographic primitive behind modern JWT HS256 tokens and nearly all robust API request signing schemes (including AWS Signature V4, strict Stripe webhook verification, and GitHub webhook payload secrets). When you cryptographically sign a JWT with the HS256 algorithm, the server actually computes HMAC-SHA256(base64url(header) + "." + base64url(payload), secret). This specific generator tool uses the exact same highly optimized crypto.subtle Web Crypto API utilized by enterprise applications, making it the perfect utility for precisely debugging raw JWT signatures during local backend development.

To thoroughly debug the full nested JSON structure of a JWT token, use our comprehensive JWT Debugger. To verify complete JWT signatures encompassing advanced key validation and expiration checks, try the JWT Signature Verifier.

Why Privacy Matters for Cryptographic Tools

Proper HMAC computation absolutely requires your secret signing key — which is undoubtedly the most critical and sensitive credential in any modern authentication system. Entering your production API signing key, webhook secret, or JWT secret into a standard server-side online tool forces that data over the network to a third-party backend, potentially exposing every single signed request or authentication token your app generates. This tool eliminates that risk entirely by running 100% locally in your browser using the native Web Crypto API. 100% private — your secret keys, raw messages, and cryptographic signatures never leave your device.

Browser Compatibility

This HMAC generator and verifier is natively compatible with all modern browsers, including Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge, by heavily leveraging the built-in HTML5 Web Crypto API. Because the heavy cryptographic lifting is completely handled by standard, highly optimized browser APIs without any backend communication, you benefit from near-instant signature generation. Furthermore, the tool operates perfectly in offline environments, allowing you to safely generate highly sensitive API signatures even when completely disconnected from the internet.

For a much more comprehensive and technical guide to securing your web applications, API endpoints, and authentication flows, read our Web Security Complete Guide.

How to Use the HMAC Generator & Verifier

  1. Enter the plain text payload or exact API message string you want to securely sign in the Message field.
  2. Paste your private cryptographic secret key or webhook signing secret in the designated Secret Key field.
  3. Select the specific HMAC algorithm (SHA-256 is highly recommended for modern applications) from the dropdown.
  4. Choose your desired output encoding format (typically raw hexadecimal or base64 string).
  5. Click the Generate HMAC button to instantly compute the cryptographic signature using the Web Crypto API.
  6. Alternatively, switch the tool to Verify mode, input an expected HMAC string, and check if the signatures match exactly.

Common Use Cases

  • Generating complex HMAC-SHA256 signatures for securing REST API request authentication (like AWS Signature V4).
  • Verifying inbound webhook signatures from essential third-party services like GitHub, Stripe, and Twilio to prevent spoofing.
  • Testing and debugging raw JWT HS256 signatures manually during local development and API troubleshooting.
  • Creating robust message authentication codes (MACs) for securing inter-service microservice communication.
  • Validating crucial API response integrity by implementing shared secret HMAC verification on the client side.
  • Teaching cryptographic concepts and the mathematical differences between plain hashes and keyed hashes to computer science students.

Frequently Asked Questions

What exactly is HMAC?

HMAC (Hash-based Message Authentication Code) is a specialized cryptographic construction that intimately combines a cryptographic hash function (like SHA-256 or SHA-512) with a secret cryptographic key to produce a unique message authentication code. Unlike plain hashing algorithms, HMAC proves both data integrity AND authenticity — only a party possessing the exact secret key can generate or verify the correct HMAC signature.

What is the difference between HMAC and regular hashing?

Regular hashing algorithms (like pure SHA-256 or MD5) act entirely deterministically, producing the exact same output for the same input regardless of who actually computes it. HMAC inherently adds a secret key into the mathematical process, ensuring that only trusted parties who know the shared key can generate or verify the resulting hash. This critical difference makes HMAC suitable for strict API authentication (verifying exactly who sent a message), while plain hashes are only used to verify integrity (ensuring the data was not corrupted).

Which HMAC algorithm should I choose for my application?

You should use HMAC-SHA256 for the vast majority of web applications — it is the absolute industry standard for modern JWT signing (the HS256 algorithm), cloud API request authentication (such as AWS Signature V4), and third-party webhook verification (like GitHub, Stripe, and Twilio). Use HMAC-SHA512 when you require an even higher security margin. You should completely avoid HMAC-SHA1 for new implementations since the underlying SHA-1 algorithm has known collision weaknesses, although HMAC-SHA1 remains cryptographically safe if required for legacy system compatibility.

How exactly is HMAC utilized inside JWTs?

JSON Web Tokens (JWTs) that are signed with the popular HS256 algorithm use HMAC-SHA256 internally. The JWT's JSON header and payload are both Base64URL-encoded and then concatenated together with a single dot character. Then, HMAC-SHA256 is computed over that concatenated string using the server's shared secret key. The resulting hash becomes the final JWT signature. This generator tool uses the exact same underlying Web Crypto API that modern browsers use for native JWT verification.

Can I use HMAC for password hashing?

No, HMAC is not designed for password hashing. While HMAC is secure, it is meant to be extremely fast, which makes it highly vulnerable to brute-force attacks if an attacker obtains the hash. For passwords, you should always use purposefully slow, key-stretching algorithms like bcrypt, Argon2, or scrypt. If you need to verify bcrypt hashes, use our dedicated Bcrypt Hash Verifier tool instead.

Is this HMAC generator safe to use with real API keys?

Yes, it is entirely safe and highly secure. This tool utilizes your browser's native Web Crypto API and runs 100% locally on the client-side. 100% private — your secret keys, messages, and resulting signatures never leave your device. You can independently verify this strict privacy by checking the Network tab in your browser's Developer Tools, where you will see exactly zero outbound data requests.

What is a timing attack in HMAC verification?

A timing attack occurs when an attacker measures exactly how long it takes your server to reject an invalid HMAC. If you use standard string equality (==), the comparison stops at the first incorrect character. By measuring the microsecond differences, attackers can guess the HMAC character by character. Always use constant-time comparison functions like crypto.timingSafeEqual().

Can HMAC prevent replay attacks?

By itself, no. HMAC only guarantees that the message hasn't been altered and came from someone with the secret key. If an attacker intercepts a valid signed request, they can resend the exact same request later (a replay attack). To prevent this, your message payload must include a unique timestamp or nonce that is verified on the server.

Related Tools