Generate HMAC signatures using SHA-256, SHA-1, or SHA-512. Output in hex, Base64, or Base64URL format. Uses the Web Crypto API — your data never leaves the browser.
Verify Signature
HMAC Generator is a free browser-based tool that computes HMAC (Hash-based Message Authentication Code) signatures using the SHA-1, SHA-256, or SHA-512 hash functions. Enter a message, provide a secret key, choose an algorithm and output format (hex, Base64, or Base64URL), and get a cryptographic signature you can use for API authentication, webhook signature verification, or data integrity checks. All computations use the browser's native Web Crypto API — your data never leaves your device.
Use HMAC Generator when debugging API authentication by comparing your computed signature against an expected value, verifying webhook signatures from services like GitHub, Stripe, or Twilio, generating test signatures for API integration testing, understanding how a third-party API's authentication mechanism works, or validating that your signing implementation in code produces the same result as the reference implementation.
Backend developers use HMAC Generator to debug webhook signature verification failures by comparing the computed and expected HMAC values; generate reference signatures for API integration tests; validate signing logic when implementing custom authentication for REST APIs; verify that HMAC-SHA-256 implementations in different languages (Go, Python, Node.js, PHP) produce the same output for the same inputs; and generate API request signatures for services that require HMAC-based authentication like AWS Signature Version 4 (which uses HMAC-SHA-256 internally).
Essential terms and definitions related to HMAC Generator.
A cryptographic algorithm that uses a hash function (SHA-256, SHA-512, etc.) combined with a secret key to generate a message authentication code. HMAC provides two guarantees: integrity (the message was not modified) and authenticity (the message was created by someone with the secret key). It is defined in RFC 2104 and widely used for API authentication, JWT signing, and webhook verification.
A browser-native JavaScript API (window.crypto.subtle) for performing cryptographic operations including hashing, signing, encryption, and key generation. Unlike pure JavaScript implementations, Web Crypto operations run in optimized native code, use the OS cryptographic library, and are not accessible from JavaScript to extract keys once imported. Available in all modern browsers in secure contexts (HTTPS/localhost).
A secret value known only to the two parties communicating — typically the API provider and the API client. In HMAC-based authentication, the shared secret is the key used to sign requests or verify webhook payloads. It must be kept confidential: anyone with the shared secret can generate valid HMAC signatures for any message.
A side-channel attack where an attacker infers information about a secret by measuring how long comparison operations take. String comparison functions stop at the first mismatched character, so comparing a valid HMAC with a forged one takes longer when more leading characters match. This leaks information about the correct signature. Timing-safe comparison functions (like Node.js crypto.timingSafeEqual) always take the same time regardless of where the mismatch occurs.
A security mechanism used by webhook providers (GitHub, Stripe, Twilio) where the provider signs the webhook payload with HMAC using a shared secret. The receiver computes the expected HMAC of the received payload and compares it with the signature in the request header. If they match, the webhook is genuine and has not been tampered with in transit. This prevents attackers from sending forged webhook payloads to your endpoint.
HMAC (Hash-based Message Authentication Code) combines a message with a secret key to produce a signature. A regular hash (SHA-256, MD5) produces the same output for the same input regardless of who runs it. HMAC requires both the original message and the secret key to reproduce the signature, making it impossible to forge without knowing the key. This adds authentication: the recipient can verify not just data integrity but also that the message was created by someone with the secret key.
HMAC-SHA-256 produces a 256-bit (64-hex-character) signature and is the most common choice for API authentication, JWT signing (HS256), and webhook verification. HMAC-SHA-512 produces a 512-bit (128-hex-character) signature and provides higher security margins, but the practical security difference is negligible for most applications — both are considered cryptographically strong. Use HMAC-SHA-256 as the default; use HMAC-SHA-512 when the system you are integrating with requires it.
Hex encoding represents each byte as two hexadecimal characters (0-9, a-f), producing a 64-character string for SHA-256. Base64 uses a 64-character alphabet (A-Z, a-z, 0-9, +, /) to represent binary data in a more compact form — SHA-256 HMAC in Base64 is 44 characters. Base64URL is a URL-safe variant that replaces + with - and / with _ and removes padding = signs, making it safe for URL parameters and JWT tokens. Use hex for readability, Base64 for general encoding, Base64URL for JWTs and URL parameters.
Most webhook providers (GitHub, Stripe, Shopify) sign their payloads by computing HMAC-SHA-256 of the raw request body using a shared secret. To verify: (1) get the raw request body as bytes, (2) compute HMAC-SHA-256 with your shared secret, (3) encode as hex, (4) compare with the signature provided in the webhook header. The comparison must use a timing-safe equality function (e.g., crypto.timingSafeEqual in Node.js) to prevent timing attacks. Enter the exact raw payload (no reformatting) and your secret here to generate the expected signature.
Yes. This tool uses the browser's native Web Crypto API — all cryptographic operations run locally in your browser process. Your message and secret key are never transmitted to any server, stored anywhere, or logged. You can verify this by running the tool while offline. For highly sensitive production keys, using a browser-based tool is safe because the computation is local, but follow your organization's key management policies regarding where secret keys can be entered.
No. HMAC is not suitable for password storage. It is designed to be fast, which is the opposite of what you want for passwords — an attacker with the secret key can test billions of passwords per second with HMAC. For password storage, use a dedicated password hashing function like bcrypt, scrypt, or Argon2 that is specifically designed to be computationally expensive. Use HMAC for authentication codes, API signatures, webhook verification, and data integrity checks.
Common errors developers encounter and how to resolve them.
HMAC signature does not match the expected value The most common causes of mismatched HMAC signatures are: (1) Encoding mismatch — check whether the expected value is in hex, Base64, or Base64URL and select the correct encoding. (2) Extra whitespace or newlines in the message or key — even a single trailing newline character will produce a completely different HMAC. (3) Encoding of the message — if the API expects the raw bytes of a JSON string, make sure you are not reformatting or pretty-printing the JSON before signing. (4) Key encoding — some APIs provide the secret as Base64 or hex and expect you to decode it before using it as the HMAC key. This tool treats the key as a UTF-8 string.
HMAC result is different when computed in different languages HMAC produces deterministic output — the same message, key, and algorithm always produce the same result regardless of the programming language. Differences are caused by encoding issues: (1) The key might be treated as a raw byte string in one language and a UTF-8 string in another. (2) The message might include a byte-order mark (BOM) in some environments. (3) Line endings might differ (\n vs \r\n). Compare the exact bytes of the message and key, not the string representations. Use this tool's output as a reference to debug which environment is applying the correct encoding.
Web Crypto API not available The Web Crypto API (window.crypto.subtle) is only available in secure contexts (HTTPS or localhost). If you are viewing this page over plain HTTP, the API will be unavailable and HMAC generation will fail. All modern browsers support Web Crypto in HTTPS contexts. If you are accessing via HTTP for development, use localhost instead of an IP address, which is also considered a secure context.