HMAC Generator & Verifier

An HMAC generator computes a Hash-based Message Authentication Code: a fixed-length tag produced from a secret key plus a message using a hash function such as SHA-256. Anyone holding the same key can recompute the tag and confirm the message is authentic and unmodified. This tool generates HMAC tags with SHA-256, SHA-512, SHA-1, or MD5 entirely in your browser — no data ever leaves your device.

Paste your message, enter your secret key (as text, hex, or base64), select SHA-256, and click Generate. The tool outputs the HMAC in hex and base64. For programmatic use, the equivalent one-liner in Python is hmac.new(key, message, hashlib.sha256).hexdigest(). Always compare signatures with a constant-time comparison to avoid timing attacks.

Switch to the Verify tab, enter the same key, message, and algorithm the sender used, then paste the signature you received. The tool recomputes the HMAC and reports MATCH or MISMATCH. A mismatch means the message was altered, the key is wrong, or the encoding (hex vs base64, uppercase vs lowercase) differs — check the troubleshooting tips below the verifier.

SHA-256 is a plain hash function: anyone can hash any message, so a bare SHA-256 digest proves nothing about who created it. HMAC combines SHA-256 with a secret key, so only key holders can produce or verify the tag. Use plain SHA-256 for integrity checks against accidental corruption (like file checksums); use HMAC when you need authentication — proof of origin.

Simply concatenating a secret with a message and hashing it is vulnerable to length-extension attacks on Merkle–Damgård hashes (MD5, SHA-1, SHA-256): an attacker who sees hash(secret ‖ message) can compute hash(secret ‖ message ‖ extra) without knowing the secret, forging valid tags for extended messages. HMAC's nested double-hash construction (with ipad and opad) was designed specifically to defeat this class of attack.

HMAC-SHA512 uses the SHA-512 hash function, producing a 128-character hex tag. Choose it when a protocol mandates 512-bit security (some government and banking standards do) or when you want extra margin against future cryptanalysis. For most API signatures and webhooks, HMAC-SHA256 is the standard choice and is faster on 32-bit systems.

Surprisingly, yes — for message authentication specifically. The famous collision attacks on MD5 and SHA-1 break plain hashing, but HMAC's security does not rely on collision resistance in the same way, and no practical attack breaks HMAC-MD5 or HMAC-SHA1 as a MAC. Still, prefer HMAC-SHA256 for anything new: it removes all doubt and costs nothing extra. This tool includes MD5 and SHA-1 only for verifying legacy systems.

Use a random key at least as long as the hash output: 32 bytes (256 bits) for HMAC-SHA256, 64 bytes for HMAC-SHA512. Shorter keys still work but reduce the security margin; longer keys are hashed down internally and give no extra benefit beyond the output size. Never use a human-memorable password directly as a key — derive one with a KDF if you must start from a password.

The encoding is just a representation — what matters is the exact bytes. The text 'Jefe' and the hex '4a656665' are the same key and produce the same tag; 'SmVmZQ==' in base64 is also identical. Mismatched signatures are most often caused by one side decoding the key as UTF-8 text while the other decodes it as hex. Use this tool's encoding selector to match whatever your API documentation specifies.

The server gives you a secret key. For each request you build a canonical string (for example: timestamp + HTTP method + path + body), compute HMAC-SHA256 with your key, and send the tag in a header like X-Signature. The server recomputes it with its copy of the key; if the tags match, the request is authentic. Stripe, GitHub, Slack, and AWS webhooks all work this way. Include a timestamp and reject old ones to block replay attacks.

HS256 in a JWT is literally HMAC-SHA256: the signature is HMAC over the base64url-encoded header and payload, keyed with your secret. So everything on this page about generating and verifying HMAC-SHA256 applies directly to validating JWTs signed with HS256. (JWTs can also use RS256/ES256, which are asymmetric digital signatures — a different mechanism where verification needs only a public key.)

This tool runs 100% in your browser: the key is processed by JavaScript on your device and is never sent to any server (you can verify this by disconnecting from the network — the tool keeps working). Even so, treat production secrets with care: for learning and for verifying test vectors this tool is ideal, but never paste a live production key into any website if your security policy forbids it. Use the built-in random key generator for experiments.

The four usual suspects: (1) key encoding — text vs hex vs base64; (2) message encoding — an extra newline, different line endings (CRLF vs LF), or Unicode normalization; (3) wrong algorithm — SHA-256 vs SHA-512 produce completely different tags; (4) truncated or case-mangled hex when copy-pasting. The Verify tab normalizes case and whitespace for you — if it still mismatches, compare byte-by-byte with the sender.

HMAC uses one shared secret: both sides can create and verify tags, so it cannot prove which side signed (no non-repudiation). A digital signature (RSA, ECDSA, Ed25519) uses a private key to sign and a public key to verify, so anyone can verify but only the key holder can sign — and signatures are non-repudiable. Use HMAC for API/webhook authentication between parties that already share a secret; use digital signatures for software distribution, certificates, and anything needing public verifiability.