HMAC Generator
Generate HMAC signatures using SHA-256, SHA-512, SHA-384, or SHA-1. Paste your message and secret key, pick an algorithm, and get the hex or Base64 output instantly. Runs entirely in your browser.
All Security ToolsAlgorithm
Verify a signature
What is HMAC and When Do You Need It
HMAC stands for Hash-based Message Authentication Code. It proves two things at once: a message has not been tampered with, and the sender holds a shared secret key. Plain hashing only covers the first part.
You will see HMAC most in API authentication. When your server generates a webhook signature and your client verifies it before processing, that is HMAC. AWS Signature Version 4, Stripe webhook verification, GitHub webhook secrets — all use HMAC-SHA-256.
This tool uses the browser’s built-in Web Crypto API, which is the same cryptographic engine your browser uses for TLS. No third-party libraries, no network calls.
What this tool does
HMAC formula (RFC 2104):
HMAC(K, m) = H( (K ⊕ opad) ‖ H( (K ⊕ ipad) ‖ m ) )
K = secret key · m = message · H = hash function · ⊕ = XOR · ‖ = concatenation · ipad/opad = fixed padding constants
Choosing the right algorithm
HMAC-SHA-256 Recommended
The industry default. 256-bit output. Used by AWS, Stripe, GitHub, PayPal, and most modern APIs. Fast and widely supported.
HMAC-SHA-512 Strong
512-bit output. Marginally slower, longer signature strings. Used when extra security margin is needed or when the system is 64-bit optimised.
HMAC-SHA-384 Strong
384-bit output, truncated from SHA-512 internally. A middle ground between SHA-256 and SHA-512. Less common in APIs.
HMAC-SHA-1 Legacy
160-bit output. SHA-1 is weak for hashing, but HMAC-SHA-1 remains secure for authentication (the key prevents collision attacks). Only use it if the system requires it.
Common Questions
Questions About HMAC
A regular hash (SHA-256, MD5, etc.) takes a message and produces a fingerprint. Anyone can compute the same hash for the same message. HMAC adds a secret key to that process, so only people who know the key can produce or verify the signature. This makes HMAC suitable for authentication, while plain hashing is only suitable for integrity checking.
The provider (e.g. Stripe, GitHub) computes HMAC-SHA-256 of the raw request body using a shared secret key and sends the result in a header. Your server does the same computation with the same key and compares. If they match, the request is genuine and unmodified. Use this tool to replicate that computation manually when debugging or testing webhooks.
Yes. This tool runs entirely in your browser using the Web Crypto API. Nothing is sent to a server. You can verify this by opening your browser’s network tab before using the tool — no outbound requests are made when you generate. That said, never use production secrets on any third-party website you cannot verify. The fact that this tool is client-side makes it safer than most, but your best option for high-stakes keys is always a local script or your server’s own HMAC library.
It depends on what the receiving system expects. Most API docs specify this explicitly. Stripe uses hex. GitHub webhook signatures use hex with a “sha256=” prefix. JWT uses Base64URL (no padding, URL-safe characters). If you are building something yourself, Base64 is more compact — 44 characters for SHA-256 vs 64 for hex. Base64URL is best for headers and URLs since it avoids special characters.
RFC 2104 recommends keys at least as long as the hash output. For HMAC-SHA-256 that means at least 32 bytes (256 bits). Keys longer than the block size (64 bytes for SHA-256) are hashed first, so there is no benefit beyond 64 bytes. In practice, generate a random 32-64 byte key using a cryptographically secure random number generator and store it securely as an environment variable, not in source code.
SHA-1 is broken for collision resistance — an attacker can craft two different messages with the same hash. But HMAC’s security does not rely on collision resistance; it relies on the hash being a pseudo-random function. HMAC-SHA-1 remains computationally secure against forgery attacks as long as the key is secret. It is still used in OAuth 1.0 and some legacy systems. Avoid it for new work, but it is safe to include for compatibility testing.