🔏 HMAC Generator

📝
🔑
Key format:
🔧
More algorithms...
📐
🔐
{{ result.hmac }}
Algorithm: {{ result.algorithmName }}
Output Length: {{ result.length }} bits
📊
{{ format.toUpperCase() }}:
{{ value }}
🧪
💡
  • Use SHA-256 or SHA-512 for modern applications
  • Keys should be at least as long as the hash output
  • Store keys securely - never hardcode in source
  • Base64 format is common for HTTP headers
  • Hex format is common for comparison/verification
⚠️

ℹ️ About HMAC Generator

HMAC (Hash-based Message Authentication Code) is a keyed message authentication code that combines the exact message bytes with a shared secret key and a cryptographic hash function. It verifies both integrity and knowledge of the secret key, but it does not encrypt the message and it is not a public-key digital signature.

The construction is defined in RFC 2104 and standardized for approved hash functions by NIST FIPS 198-1. SHA-224, SHA-256, SHA-384, and SHA-512 come from the NIST Secure Hash Standard (FIPS 180-4); SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are specified in FIPS 202.

Practical uses:

  • Signing API requests such as METHOD + path + timestamp + body before sending them to a server.
  • Verifying webhook payloads by recomputing the HMAC over the raw request body and comparing it with the provider's signature header.
  • Checking JWT HMAC signatures such as HS256, HS384, and HS512 over the base64url(header) + "." + base64url(payload) signing input.
  • Creating test vectors for protocol implementations that require HMAC-SHA256, HMAC-SHA512, or SHA-3 based HMAC values.

Input and output details:

  • Text keys are treated as UTF-8 text; hex and Base64 key modes decode the key into raw bytes before HMAC is calculated.
  • Hex output is common in logs and command-line tools, Base64 is common in HTTP headers, and Base64 URL output is useful for JWT and URL-safe tokens.
  • If a key is longer than the hash block size, HMAC hashes it first; for new systems, use a random key at least as long as the selected hash output, such as 32 bytes for HMAC-SHA256.

Examples:

  • Webhook body: {"event":"payment.success","amount":1000} with a provider secret to reproduce a header such as X-Signature.
  • API request string: GET\n/api/v1/users\n1716239022 with a client secret for deterministic request signing.
  • JWT signing input: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ with HMAC-SHA256 and Base64 URL output.

Security and limitations:

  • Prefer SHA-256, SHA-512, or SHA3-256 for new designs. MD5, SHA-1, and RIPEMD-160 are legacy choices; RFC 6151 updates the security considerations for MD5 and HMAC-MD5.
  • Keep production secrets out of tickets, chat, source code, logs, and shared screenshots. Rotate a secret immediately if it has been pasted into an unsafe place.
  • Compare HMACs over the exact same bytes, including line endings, JSON spacing, URL encoding, and timestamp strings. A semantically identical message can produce a different HMAC if its bytes differ.
  • Use a constant-time comparison in production verification code to avoid timing leaks. This page is useful for generation and debugging, not as a replacement for server-side signature verification.
  • The browser UI calculates HMACs locally; the public API endpoint processes submitted values server-side, so avoid sending real production keys unless that matches your threat model.

API Usage Example:

POST /api/tools/crypto/hmac
Content-Type: application/json

{
    "text": "Hello World",
    "key": "my-secret-key",
    "keyFormat": "text",
    "algorithm": "sha256",
    "outputFormat": "hex"
}
Ready