What HMAC adds on top of a hash
A plain cryptographic hash fingerprints data: anyone can recompute SHA-256(message) and compare. An HMAC (Hash-based Message Authentication Code) mixes a secret key with the message before hashing so that only parties who know the key can produce or verify the tag. The result is a fixed-length digest—often shown as hex—that authenticates both integrity and origin under the shared-secret model.
HMAC is widely used for API request signatures, webhook verification, and signed cookies. It does not encrypt the message; if you need confidentiality, use a cipher or TLS. It also does not replace public-key signatures when parties should not share a single secret.
Compute a modern tag with HMAC SHA-256 using a sample message and a test-only secret.
Subtools in this family
The hub offers the same HMAC construction over three underlying hash functions:
- HMAC SHA-256 — preferred default for new integrations; common in AWS-style signing, JWT HS256, and many webhook schemes.
- HMAC SHA-1 — still encountered in older APIs; migrate when you control both ends.
- HMAC MD5 — legacy only; useful for understanding old checksum-style MACs, not for new security designs.
Pick the subtool that matches the algorithm name in the protocol you are implementing. A SHA-256 HMAC will not verify against an MD5 HMAC of the same message and key.
How HMAC is constructed (intuition)
RFC 2104 defines HMAC roughly as hashing a combination of the key and message with inner and outer padded key blocks. The important engineering properties:
- The key remains secret; the digest alone should not reveal it.
- Changing any bit of the message (or the key) yields a different tag with overwhelming probability.
- Verification is a recompute-and-compare operation—ideally in constant time for security-sensitive code paths.
You do not need to implement the padding by hand when a standard library function HMAC(hashAlg, key, message) exists—and you should prefer those libraries in production.
Keys, messages, and encodings
Key quality. Use long, random keys from a CSPRNG. Human passphrases are weaker unless run through a proper KDF. Do not use the same key for two different protocols without domain separation.
Message bytes. HMAC authenticates exact bytes. JSON with different key order or whitespace produces a different tag even when semantics match. Canonicalize structured data before signing if multiple producers exist.
Output encoding. Libraries may return raw bytes, hex, or Base64. Two systems comparing tags must agree on encoding and letter case for hex. JWT and many HTTP schemes use Base64URL rather than hex—match the spec.
Typical workflows
Webhook verification. A provider sends a payload plus an X-Signature header. Your server recomputes HMAC over the raw body with the shared secret and compares.
API request signing. A canonical string (method, path, timestamp, body hash) is covered by HMAC so intermediaries cannot alter the request unnoticed.
Learning JWT HS256. JSON Web Tokens signed with HS256 are HMAC-SHA-256 over base64url(header) + "." + base64url(payload). See also the JWT hub for encode/decode/verify flows.
Choosing MD5, SHA-1, or SHA-256
Collision attacks against MD5 and SHA-1 matter most for unkeyed hashing and certificate misuse. HMAC-MD5 and HMAC-SHA-1 are stronger than bare MD5/SHA-1 for authenticity in some threat models, but modern guidance still steers new designs to HMAC-SHA-256 (or stronger) for algorithm agility and simplicity of policy. If a vendor only offers HMAC-MD5, treat it as a compatibility constraint and isolate that integration.
Common mistakes
- Publishing the secret in mobile apps or front-end JavaScript and expecting HMAC to prove anything to the server.
- Hashing with SHA-256 but forgetting the HMAC key step (or the reverse).
- Signing a parsed-and-restringified body instead of the raw request bytes.
- Using timing-unsafe string equality (
===in some contexts) for tag comparison in high-assurance code. - Rotating keys without a dual-verify window, causing sudden verification failures.
Limitations and environment
These browser tools help you generate and compare digests while learning or debugging. They are not a key-management system. Keep real production secrets in serverside stores; use throwaway keys for demos.
Summary
HMAC turns a hash function into a keyed authenticator. This hub provides HMAC-MD5, HMAC-SHA-1, and HMAC-SHA-256 so you can match protocol requirements and see how digests change with message or key. Prefer SHA-256 for new work, canonicalize bytes before signing, and remember that HMAC authenticates—it does not encrypt.