HMAC Generator

HMAC Generator: Keyed Hash Authentication for Message Integrity and Verification

The HMAC Generator creates Hash-based Message Authentication Codes using the SHA family of cryptographic hash functions, providing a reliable mechanism for verifying both the integrity and authenticity of messages and data payloads. HMAC, formally defined in RFC 2104 and standardized by NIST in FIPS 198-1, combines a secret cryptographic key with a message through a specific construction involving an underlying hash function to produce a fixed-size authentication tag. Unlike a plain cryptographic hash that anyone can compute from the same input, an HMAC requires knowledge of the secret key to both generate and verify, making it impossible for an attacker who intercepts a message to forge a valid authentication code without possessing the key. This tool supports four HMAC variants: HMAC-SHA1 (160-bit output), HMAC-SHA256 (256-bit output), HMAC-SHA384 (384-bit output), and HMAC-SHA512 (512-bit output), with results displayed in both hexadecimal and Base64 encoding formats for maximum compatibility with different systems and APIs. All computation in this tool runs entirely within your browser using the Web Crypto API's native HMAC implementation, which provides hardware-accelerated, constant-time operations resistant to timing side-channel attacks.

Technical Deep Dive: HMAC Construction, Security Properties, and Key Requirements

The HMAC construction is elegantly simple yet cryptographically powerful. Given a hash function H, a secret key K, and a message M, HMAC is computed as H((K XOR opad) || H((K XOR ipad) || M)), where ipad (inner padding) is the byte 0x36 repeated to the hash function's block size, and opad (outer padding) is the byte 0x5C repeated similarly. The most critical advantage of HMAC over naive constructions like hash(key || message) is its resistance to length extension attacks. The security proof for HMAC shows that it is secure as long as the underlying hash function's compression function is a pseudorandom function (PRF). HMAC provides a different security guarantee than digital signatures using RSA or ECDSA. HMAC is symmetric because both parties share the key, while signatures are asymmetric.

Real-World Use Cases: API Signing, Webhook Verification, and Protocol Authentication

HMAC is one of the most practically deployed cryptographic primitives in modern software development. Amazon Web Services uses HMAC-SHA256 as the core of its Signature Version 4 signing process. Stripe, GitHub, Slack, Twilio, and Shopify all use HMAC-based webhook verification mechanisms. JSON Web Tokens (JWTs) with the HS256 algorithm use HMAC-SHA256 to sign the token's header and payload. TOTP (Time-based One-Time Password) algorithms used by authenticator apps generate six-digit codes using HMAC-SHA1 applied to a shared secret and the current time period.

HMAC Compared to Other Authentication Methods and Best Practices

A simple SHA-256 hash provides integrity verification but no authentication. HMAC adds a secret key to the equation. Never use hash(key + message) as a substitute for proper HMAC. Select HMAC-SHA256 as your default algorithm for new applications. For legacy checksum verification, the MD5 Generator can compute quick checksums. For encrypting data, use our AES Encryption tool or the RSA Encryption tool. Browse our full collection on the Encode/Decode tools page.

Webhook and API Signature Debugging Workflow

Load the webhook payload sample to see a compact JSON event signed with HMAC-SHA256, then paste a provider header value such as sha256=... into the expected signature field to compare it with the generated hex or Base64 result. If comparison fails, verify the exact raw request body, newline placement, timestamp prefix, selected hash algorithm, and environment-specific secret before changing application code. After generating a signature, copy it into your test request header, reuse it as a message for chained signing experiments, or encode related payloads with the Base64 Encoder.

Sample And Checks

Sample input: message event=invoice.paid&amount=24875, secret whsec_demo, algorithm HMAC-SHA256.

Expected hex output: 6bffdd4b550961d12dc3c4d20f4263c5e8cedcd5bde8132b84c730c5f77fb694. Expected Base64 output: a//dS1UJYdEtw8TSD0JjxejO3NW96BMrhMcwxfd/tpQ=.

• Common errors: using a plain SHA hash instead of HMAC, comparing hex to Base64, changing whitespace in the signed message, and testing with the wrong environment secret.
• Next checks: validate provider payloads with the Webhook Signature Validator, build canonical request headers with the HMAC Header Generator, encode signed payloads with the Base64 Encoder, and inspect HS256 token claims with the JWT Decoder.

Privacy note: HMAC calculation is local, but shared secrets and signed messages should be treated as credentials. Use demo secrets, rotate exposed keys, and redact production headers before sharing output.