Compute HMAC (Hash-based Message Authentication Code) signatures online. Supports SHA-1, SHA-256, and MD5 algorithms.
HMAC (Hash-based Message Authentication Code) is a cryptographic construction that combines a hash function with a secret key to produce an authentication code. Unlike plain hashing (which anyone can compute), HMAC verification requires possession of the same secret key — providing both data integrity (detecting any modification) and authentication (proving the sender knows the key). HMAC is the basis for most API request signing systems, webhook signature verification, and token generation schemes.
This generator computes HMAC values using your choice of underlying hash function (SHA-256, SHA-512, SHA-384, SHA-1, MD5) and a secret key you provide. The HMAC is displayed in hexadecimal and Base64 encodings. All computation occurs locally in your browser using the Web Crypto API's SubtleCrypto.sign() method — your key and message are never transmitted to any server.
The HMAC construction (RFC 2104) is: HMAC(K, M) = H((K' XOR opad) || H((K' XOR ipad) || M)), where H is the hash function, K is the key (padded/hashed to block size as K'), ipad and opad are fixed padding constants (0x36 and 0x5C repeated), and || denotes concatenation. This double-hash construction prevents length extension attacks that would compromise plain H(K||M) authentication.
HMAC inherits the collision resistance of its underlying hash function but adds key-dependent security: without the key, an attacker cannot compute a valid HMAC even if they can observe many valid (message, HMAC) pairs. HMAC remains secure even when the underlying hash function has some collision vulnerabilities, as proven by Bellare, Canetti, and Krawczyk — HMAC-MD5 remains computationally secure for authentication despite MD5's collision vulnerabilities.
Most API authentication schemes use HMAC to sign requests. AWS Signature Version 4 computes an HMAC-SHA256 chain: first over the canonical request, then over a string-to-sign derived from date, region, service, and the request hash, using a derived signing key from the user's AWS secret access key. This chained HMAC scheme limits the scope of each derived signing key to a specific date, region, and service.
GitHub, Stripe, Shopify, and most modern webhook providers verify webhook delivery using HMAC-SHA256: the provider signs the payload with a shared secret using HMAC-SHA256 and includes the hex or Base64 signature in the request headers. Recipients recompute the HMAC on the received payload using the same shared secret and compare with the provided signature to verify authenticity and detect tampering during transmission.
HMAC is a symmetric authentication scheme — the same secret key is used to both generate and verify the code. Any party with the key can generate valid HMACs, so HMAC doesn't provide non-repudiation (you can't prove which party generated the code). Digital signatures use asymmetric key pairs: the private key signs, the public key verifies. Only the private key holder can sign, enabling non-repudiation. HMAC is faster and simpler; digital signatures enable public verification without sharing secrets.
Use HMAC-SHA256 for most applications — it is the current industry standard, used by AWS, GitHub, Stripe, and Google APIs. Use HMAC-SHA512 for applications requiring higher security margins or compatibility with systems specifying SHA-512. Avoid HMAC-MD5 and HMAC-SHA1 for new designs, though both remain computationally secure for MAC purposes — the risk is more about perception and future-proofing than current vulnerability.
HMAC key length should match the hash output size for optimal security: at least 32 bytes (256 bits) for HMAC-SHA256, 64 bytes for HMAC-SHA512. Keys shorter than the hash output size reduce security; keys longer than the block size are hashed down to block size. Random keys generated using a cryptographic RNG are essential — human-chosen or derived keys from low-entropy sources significantly reduce HMAC security.
Computing the HMAC itself is not the vulnerability — comparing the computed HMAC against the received value is. Standard string/byte comparison functions return early when the first non-matching byte is found, leaking timing information that can reveal the expected HMAC byte-by-byte through repeated timing measurements. Always use constant-time comparison functions (e.g., hmac.compare_digest() in Python, crypto.timingSafeEqual() in Node.js) to prevent timing side-channel attacks.
No — HMAC is fast (designed for high throughput in signing operations), making it unsuitable for password hashing where deliberate slowness is required. An attacker with GPU hardware can compute billions of HMAC operations per second. For password storage, use dedicated slow password hashing functions: bcrypt, scrypt, or Argon2id. These are specifically designed to be memory-hard and CPU-intensive to make brute-force attacks expensive.