Skip to main content
Hashing

HMAC Authentication Code Generator

Generate lowercase-hex HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512 from UTF-8 message and literal UTF-8 secret using Web Crypto. Essential for developers testing API signature verification, webhook authentication, and message integrity protocols. Supports all three SHA-2 family truncation levels.

Hashing tools

In brief

Reproduce shared-secret MAC test vectors locally while distinguishing HMAC from encryption and public-key signatures and protecting secret-key handling.

What this tool supports

  • Message and secret are literal browser strings encoded as UTF-8; hexadecimal/Base64 key text is not decoded.
  • Web Crypto imports the secret as a non-extractable raw HMAC key and signs the message with SHA-256/384/512.
  • Lowercase hexadecimal MAC, downloadable as hmac.txt.
  • Use Hash Generator for unkeyed integrity or JWT Verifier for a complete token verification workflow.
  • No. It authenticates with one shared secret; it neither hides the message nor supports public verification.

How to use HMAC Authentication Code Generator

Complete a verifiable HMAC Authentication Code Generator workflow in this browser.

  1. 1

    Step 1

    Provide the exact input

    Message and secret are literal browser strings encoded as UTF-8; hexadecimal/Base64 key text is not decoded.

  2. 2

    Step 2

    Set the available controls

    Choose SHA-256, SHA-384, or SHA-512 and optionally enable live updates.

  3. 3

    Step 3

    Run the operation

    Web Crypto imports the secret as a non-extractable raw HMAC key and signs the message with SHA-256/384/512.

  4. 4

    Step 4

    Verify the result

    Check against RFC 4231 and compare MAC bytes using a constant-time verifier in production.

  5. 5

    Step 5

    Continue or export

    Use Hash Generator for unkeyed integrity or JWT Verifier for a complete token verification workflow.

Common mistakes

Ignoring Unicode normalization or line-ending differences in the message

Consequence: HMAC authenticates exact bytes. Visually similar NFC and NFD text, or LF and CRLF messages, produce different UTF-8 byte sequences and therefore different MACs.

Fix: Apply only the normalization required by the protocol and compare the exact message bytes before investigating the algorithm.

Using an HMAC as encryption or as a publicly verifiable signature

Consequence: The message remains readable, and anyone who can verify the HMAC must possess the same shared secret and can also generate a valid MAC.

Fix: Use authenticated encryption when confidentiality is required, or a digital-signature scheme when verification must not reveal signing authority.

Overlooking this edge case: Why does a published hex-key vector not match?

Consequence: Typing hex characters uses their UTF-8 character bytes, not the bytes represented by that hex.

Fix: Convert key material to the exact byte representation required by the protocol before comparison.

Best practices

  • Check against RFC 4231 and compare MAC bytes using a constant-time verifier in production.
  • Convert key material to the exact byte representation required by the protocol before comparison.
  • Use high-entropy protocol keys and rotate them outside this browser tool.

Connected workflows

Reproduce and verify a protocol HMAC vector

HMAC Authentication Code GeneratorHash GeneratorHMAC JWT Verifier

Use Hash Generator for unkeyed integrity or JWT Verifier for a complete token verification workflow.

  1. Choose a published test vector or a non-production protocol key
  2. Confirm the exact message bytes, key bytes, SHA variant, and expected hex casing
  3. Generate the MAC and compare it byte-for-byte with the reference
  4. Verify the same vector with a constant-time comparison in the receiving implementation

Browser limitations

  • Typing hex characters uses their UTF-8 character bytes, not the bytes represented by that hex.
  • Full message and key strings remain in memory and the implementation is not streaming.
  • SubtleCrypto availability depends on a secure context.

Authoritative resources

Web Cryptography Level 2: HMACPublisher: W3C · Reviewed: 2026-07-26RFC 4231: HMAC-SHA Test VectorsPublisher: RFC Editor · Reviewed: 2026-07-26FIPS 198-1: HMACPublisher: NIST · Reviewed: 2026-07-26

Concrete examples

Input
Message: what do ya want for nothing? Secret: Jefe Algorithm: SHA-256
Result
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

This is RFC 4231 test case 2 using literal ASCII/UTF-8 key Jefe.

Frequently asked questions

Are the message and secret interpreted as text or decoded key bytes?

Message and secret are literal browser strings encoded as UTF-8; hexadecimal/Base64 key text is not decoded.

Why does a published hex-key vector not match?

Typing hex characters uses their UTF-8 character bytes, not the bytes represented by that hex.

Does HMAC encrypt or provide a public signature?

No. It authenticates with one shared secret; it neither hides the message nor supports public verification.

How can I reproduce an RFC 4231 test vector safely?

Check against RFC 4231 and compare MAC bytes using a constant-time verifier in production.

Are the message or secret transmitted or persisted?

Message and secret stay in memory in this browser; Web Crypto may require HTTPS. Do not expose or reuse production secrets.

When should I use Hash Generator or JWT Verifier instead?

Use Hash Generator for unkeyed integrity or JWT Verifier for a complete token verification workflow.

Privacy and offline behavior

Message and secret stay in memory in this browser; Web Crypto may require HTTPS. Do not expose or reuse production secrets.