EasyDeveloper

HMAC Generator

Sign a message with a secret key using HMAC-SHA256 or HMAC-SHA512, right in your browser.

Local ProcessingYour data stays in your browser. Nothing is uploaded.

HMAC - hash-based message authentication code - is a hash that also requires a secret key. Where a plain hash lets anyone verify that data has not changed, an HMAC lets only the parties who share the secret produce and check a valid signature. That is why it sits behind API authentication, webhook verification and signed request bodies across the web.

Enter the message and a secret key, pick SHA-256 or SHA-512, and press Sign. The tool computes the MAC with the browser's Web Crypto engine and returns the hex digest. Because both sides compute the same value from the same key, an API server can confirm that a request genuinely came from the holder of the key.

The key point about HMAC is that it authenticates, it does not encrypt. The message itself is not hidden - HMAC proves the message was signed by someone holding the key and has not been tampered with in transit. Everything here runs locally, so neither the message nor your key leaves your machine.

Features

  • Sign any message with HMAC-SHA256 or HMAC-SHA512 using a secret key.
  • Computed with Web Crypto - the same native HMAC engine browsers use for TLS.
  • Uppercase output option for tools that expect it.
  • Empty-key guard: signing without a secret is refused with a clear error.
  • UTF-8 aware for both the message and the key.
  • Runs entirely in your browser - your message and key never leave your device.

How to Use

  1. 1

    Enter the message

    Type or paste the data you want to sign - an API request body, a webhook payload, or a canonical string your service defines.

  2. 2

    Add the secret key

    Enter the shared secret. Both sides must use the same key bytes; a different key produces a completely different signature.

  3. 3

    Pick the hash function

    Choose SHA-256 for most cases or SHA-512 for a longer MAC. Use the same algorithm your server-side code uses.

  4. 4

    Sign and compare

    Press Sign to get the hex MAC. Compute the expected value server-side and compare byte-for-byte - a match confirms the message was signed by the key holder.

  5. 5

    Copy the signature

    Use Copy to place the MAC in a request header such as X-Signature, a form field or a comparison script.

Example

HMAC-SHA256 of "hello" with key "secret"

Message: hello
Key: secret
Algorithm: SHA-256

↓

88aab3ede8d3adf94d26ab90d3bafd4a2083070c3bcce9c014ee04a443847c0b

Common Problems

Using a plain hash instead of HMAC

A plain SHA-256 of the payload proves nothing about who sent it - anyone can compute it. HMAC binds the signature to the secret key, which is what makes it an authentication mechanism rather than just a checksum.

Comparing signatures insecurely

Comparing two hex strings with === is vulnerable to timing attacks. Always use a constant-time comparison on both sides, such as crypto.timingSafeEqual.

Mismatched encoding between systems

The signature depends on the exact bytes of both message and key. If your server signs a UTF-8 string while you sign a Latin-1 string, or one side appends a newline, the MACs differ.

Reusing an HMAC key across purposes

Use separate keys for separate systems. A key shared between an API and a webhook means compromising one signing stream leaks trust into the other.

Getting the canonical string wrong

Many APIs define exactly which fields, in which order and with which separators go into the signed message. A mismatch between your canonical string and the server's produces a valid-looking but rejected MAC. Sign exactly what the documentation specifies, byte for byte.

Technical Details

HMAC is computed with crypto.subtle.importKey and crypto.subtle.sign using the HMAC algorithm with SHA-256 or SHA-512. The key is imported as raw bytes in the browser; nothing is transmitted.

The MAC is produced over the exact UTF-8 bytes of the message with the exact UTF-8 bytes of the key. Any difference on either side yields a completely different digest.

Output is lowercase hex. The SHA-256 variant produces a 64-character MAC; SHA-512 produces 128 characters.

HMAC is secure against length-extension attacks that break naive keyed hashes, which is precisely why it is preferred for authenticating messages when you cannot afford a full signature scheme.

This tool authenticates; it does not encrypt. The message stays readable and the MAC only proves it was produced by a party holding the key.

The result here is hex-encoded for display and copying. In many API integrations the same value is transmitted as base64 or as raw bytes - the MAC itself is identical regardless of how you serialize it.

Frequently Asked Questions

What is the difference between a hash and an HMAC?

A hash has no secret - anyone can compute it. An HMAC combines a hash with a secret key, so only parties who share the key can produce or verify a valid MAC. Use a hash for integrity, an HMAC for authenticity.

Where is HMAC used in practice?

API request signing, webhook verification, signed URLs, database record authentication and TLS itself (HMAC-based ciphersuites). When a service asks you to sign a request with a shared secret, it is almost always HMAC.

Is my secret key safe if I paste it here?

From a privacy standpoint, yes - the key is used in your browser and never uploaded. From a security standpoint, treat real keys as secrets and avoid pasting production keys into any tool. For testing, generate a throwaway key first.

Which is better, HMAC-SHA256 or HMAC-SHA512?

Both are strong. SHA-512 produces a longer MAC and runs faster on 64-bit hardware, but SHA-256 is more widely supported. Match whatever your server-side library expects rather than mixing algorithms between the two sides.

Does HMAC hide the message?

No. HMAC authenticates but does not encrypt. The message is still visible to anyone who sees it; the MAC proves it was signed by the key holder and not altered. If you need secrecy too, combine HMAC with encryption.

Should I use HMAC or a digital signature?

HMAC is symmetric: both sides share one secret key. A digital signature is asymmetric - a private key signs and a public key verifies. Choose HMAC when you control both ends and can share a secret; choose signatures when many parties must verify without receiving your secret.

Data & Privacy

Your data stays in your browser. Nothing is uploaded.

Processing
Local
Upload
None
Server Storage
None
Account
Not required

Related Tools

JWT Decoder

Inspect the header, payload and claims of a JSON Web Token - decoded locally, never uploaded.

Security & Tokens

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests of any text, in your browser.

Security & Tokens

Random String Generator

Generate secure random strings and passwords with control over length and character set.

Security & Tokens

UUID Generator

Generate random UUID v4 identifiers in bulk, with or without dashes, in your browser.

Security & Tokens

JWT Validator

Check a JWT's structure and time claims - signature is never verified, so the verdict is about usability, not authenticity.

Security & Tokens

Base64 Encode & Decode

Convert text to Base64 or decode it back, with an optional URL-safe mode - all in your browser.

Encoding & Conversion

Related Guides

JWT Header Explained: alg, typ and kid

The JWT header is the first base64url segment and declares the signing algorithm. Learn what alg, typ and kid mean and why alg=none is a known attack vector.

Hash vs Encryption: What Is the Difference?

Hashing is one-way and deterministic; encryption is two-way with a key. Learn which protects passwords vs data in transit, and why the two differ.