HMAC (Hash-based Message Authentication Code) is a cryptographic mechanism that combines a secret key with a hash function to verify both the integrity and authenticity of a message. It works by processing the message together with the secret key through two rounds of hashing—inner and outer padding—making it resistant to length extension attacks. Unlike a simple hash, HMAC can only be verified by someone who possesses the same secret key.

HMAC-SHA256 produces a 256-bit (32-byte) output and is widely used for API authentication, JWT signing, and general message integrity. HMAC-SHA512 produces a 512-bit (64-byte) output, offering a higher security margin. SHA-512 is often faster on 64-bit systems due to its internal 64-bit word size. For most applications, SHA-256 provides an excellent balance of security and performance. Use SHA-512 when you need the extra security margin or are working in high-assurance environments.

HMAC is ideal for:

• API Authentication — Signing requests between client and server (e.g., AWS Signature v4, Stripe webhooks).
• JWT Tokens — Signing JSON Web Tokens with HS256/HS512 algorithms.
• Data Integrity — Ensuring messages haven't been tampered with during transit.
• CSRF Tokens — Generating and validating anti-CSRF tokens.
• Password Reset Links — Creating time-limited, tamper-proof tokens.

Yes, HMAC is considered highly secure for API authentication when used correctly. Key security practices include: using a cryptographically random key of at least 32 bytes (256 bits), keeping the key strictly confidential (never expose it in client-side code), using HTTPS for all communications, and including a timestamp or nonce to prevent replay attacks. Major platforms like AWS, Google Cloud, and GitHub use HMAC-based signatures extensively.

The recommended key length depends on the hash algorithm:

• SHA-256: At least 32 bytes (256 bits) for optimal security. Keys longer than 64 bytes are hashed down to 32 bytes internally.
• SHA-512: At least 64 bytes (512 bits). Keys longer than 128 bytes are hashed down to 64 bytes.
• SHA-1: At least 20 bytes (160 bits), though SHA-1 is no longer recommended for new applications.

Always use a cryptographically secure random generator to create keys. Avoid using predictable values like passwords or dictionary words.

A regular hash (like plain SHA-256) only provides integrity—anyone can compute the hash of a message. HMAC adds authentication through a secret key, meaning only parties with the key can generate or verify the code. Additionally, HMAC is resistant to length extension attacks that affect plain Merkle-Damgård hash functions like SHA-256 when used naively for message authentication.

HMAC alone is not suitable for password storage because it's designed to be fast, while password hashing should be deliberately slow to resist brute-force attacks. For password storage, use dedicated algorithms like bcrypt, scrypt, Argon2, or PBKDF2. However, HMAC can be used as part of a pepper strategy, where an application-wide secret key is combined with the password before hashing with a KDF.

Hex (Hexadecimal): Each byte is represented as two characters (0-9, a-f). A 32-byte HMAC-SHA256 becomes 64 hex characters. Hex is human-readable and easy to compare byte-by-byte.

Base64: Encodes 3 bytes into 4 characters using a 64-character alphabet (A-Z, a-z, 0-9, +, /). A 32-byte HMAC becomes 44 Base64 characters (with = padding). Base64 is more compact, making it ideal for HTTP headers and JSON payloads.

Choose based on your application's requirements—both encode the same underlying binary data.

HMAC-SHA1 is still considered secure for message authentication, despite SHA-1 being broken for collision resistance. This is because HMAC's security relies on the pseudorandomness of the underlying compression function, not collision resistance. However, for new applications, SHA-256 or SHA-512 is strongly recommended to align with modern security standards (FIPS 140-3, PCI DSS 4.0) and to future-proof your implementation.

Verification involves recomputing the HMAC on the server using the same secret key and comparing it with the received value. Always use a constant-time comparison to prevent timing attacks. Example in Node.js:

const crypto = require('crypto');
const receivedHmac = req.headers['x-signature'];
const computedHmac = crypto
  .createHmac('sha256', secretKey)
  .update(payload)
  .digest('hex');
// Constant-time comparison
if (crypto.timingSafeEqual(
  Buffer.from(receivedHmac),
  Buffer.from(computedHmac)
)) {
  // HMAC is valid
}

Most server frameworks (Express, Django, Rails, etc.) have built-in or library support for HMAC verification.