An HMAC calculator computes a keyed-hash message authentication code from a shared secret and an exact message, returning a fixed-length tag in hexadecimal or Base64 that a verifier holding the same secret can recompute to confirm the message was not modified in transit. The calculator combines a cryptographic hash function, typically SHA-256, SHA-384, or SHA-512, with the secret key twice, once inside and once outside the hash compression, so an attacker who can read the message still cannot forge a valid tag without the key. What the calculator does NOT do is hide the message: HMAC authenticates bytes, it does not encrypt them. A reliable browser-based HMAC calculator, such as the HMAC Generator, lets you choose the hash, paste the key and message as UTF-8 text or raw hex bytes, and copy the resulting tag without sending inputs to a remote server.
The reason people search for an HMAC calculator is usually one of three tasks: signing an outgoing API request, verifying an incoming webhook payload, or reproducing a published test vector during development. Each task has the same core requirement, which is to match the protocol's exact bytes and chosen algorithm, but each exposes a different pitfall. The sections below cover what the calculator produces, how to choose between SHA-256, SHA-384 and SHA-512, a step-by-step workflow, and the encoding and security details that decide whether two calculators agree on the same tag.
What an HMAC Calculator Returns
Every HMAC calculator performs the same mathematical construction defined in RFC 4231 and the Web Cryptography API. You supply a key and a message; the tool pads the key to the hash block size, XORs it with an inner constant, hashes the result with the message, then XORs the key with an outer constant and hashes that combination. The output is a tag of fixed length determined solely by the chosen hash function.
Three properties hold across every correct HMAC calculator:
- The tag length depends only on the hash: SHA-256 produces 32 bytes, SHA-384 produces 48 bytes, and SHA-512 produces 64 bytes.
- The same key, the same message bytes, and the same hash always produce the same tag, regardless of which calculator computes it.
- The tag reveals nothing about the message content; it only proves that the holder of the secret saw those exact bytes.
The calculator formats the raw bytes for display in lowercase hexadecimal or standard padded Base64. Those two renderings describe identical bytes — a hex string is not "more secure" or "more compatible" than the Base64 form, and a protocol will specify which one it expects. The HMAC Generator surfaces both formats so you can copy whichever one your client or server requires.
Comparing SHA-256, SHA-384 and SHA-512 for HMAC
The choice of hash is the single biggest factor in calculator output. A spec that names HMAC-SHA-256 cannot be satisfied with SHA-384, and vice versa, because the tag lengths differ and verification will fail. Use the table below to map the three options the calculator exposes to their published characteristics. For a deeper walkthrough of generating tags with each of these hashes, see the HMAC-SHA-256, SHA-384 and SHA-512 generation guide.
| Hash | Tag length (bytes) | Hex characters | Standard Base64 length | Typical use cases |
|---|---|---|---|---|
| SHA-256 | 32 | 64 | 44 | REST API request signing, Stripe-style webhook headers, JWT HS256 |
| SHA-384 | 48 | 96 | 64 | Higher-assurance variants of protocols that name SHA-384 explicitly |
| SHA-512 | 64 | 128 | 88 | JWT HS512, long-tag protocols, environments where 64-bit word alignment matters |
These are defined values from NIST FIPS 198-1 and the SHA-2 family specifications, not computed outputs. The numbers do not shift between calculators because the underlying hash is identical. If a published test vector for the same hash disagrees with the calculator, the difference lies in the key bytes or message bytes, never in the hash arithmetic.
Calculate an HMAC From Key and Message
The workflow below matches the verified steps for the HMAC Generator and applies to most other calculators as well. Follow them in order so each input is settled before you generate.
- Confirm the protocol names the exact hash — SHA-256, SHA-384, or SHA-512 — and that it expects a full HMAC tag, not a truncated prefix or a pre-hashed message.
- Choose UTF-8 or hex input independently for the key and the message. Most specs treat the key as raw bytes and the message as text, but each side has its own selector on the HMAC Generator.
- Paste the exact bytes without extra formatting: no 0x prefixes, no spaces, no colons, no trailing newline unless the spec says one belongs there. The HMAC Generator rejects empty keys and empty messages to prevent an accidental click from producing a meaningless tag.
- Generate the tag, then copy the hex or standard Base64 rendering as the protocol specifies. Convert or truncate only when the spec explicitly says to do so — never by eye.
- Recompute the tag on the verifier side with the same hash, key, and message bytes. A match confirms the message was not modified and the sender knew the secret.
To verify the calculator against a known-good answer, run RFC 4231 Test Case 1: key = 0x0b repeated 20 times, message = the ASCII string Hi There, hash = SHA-256. The expected HMAC-SHA-256 tag is b0344c61d8db38535ca8afceaf0bf12b 881dc200c9833da726e9376c2e32cff7. The HMAC Generator returns the same 64-character lowercase hex string, confirming it agrees with the RFC's reference implementation.
Why Two HMAC Calculators Disagree
If two calculators produce different tags for what looks like the same input, the inputs are not actually the same. Common sources of mismatch, in roughly the order they bite during integration work:
- Hash mismatch. SHA-256 and SHA-384 produce tags of different lengths and different byte values; a verifier configured for one will reject the other.
- Key encoding drift. A key pasted as text becomes UTF-8 bytes inside the calculator, while a key pasted as hex becomes raw bytes. A 32-character ASCII string and its 64-character hex representation describe completely different secrets.
- Message whitespace. Trailing newlines, carriage returns, or trailing spaces are part of the message. Two systems that serialize JSON differently will hash different byte streams.
- Tag truncation or prefixing. Some protocols take only the first N bytes of the tag, prepend an algorithm identifier, or wrap the value in a structured envelope. The calculator outputs the full raw tag; the protocol rule is responsible for any further transformation.
- Base64 variants. Standard padded Base64, Base64url (with - and _), and raw Base64 without padding are not interchangeable. The HMAC Generator emits standard Base64 with padding; a verifier expecting Base64url will need a conversion step.
Whenever a tag fails to match, walk this list from the top before suspecting the calculator. The HMAC Generator exposes its hash, key encoding, and message encoding as visible inputs precisely so a divergence becomes obvious.
Key and Message Encoding Choices
The calculator offers two ways to enter each field, and choosing the wrong one is the most common cause of failed handshakes. Text mode encodes the string as UTF-8, which means accented letters, CJK characters, and emoji each expand to two, three, or four bytes. A reader who pastes the word "café" as text sees 5 bytes (c, a, f, then 0xC3 0xA9); the same word entered as the hex string 636166C3A9 produces the same 5 bytes.
Hex mode is stricter: it accepts only an even number of hexadecimal digits and preserves every byte exactly, including zero bytes that text mode cannot represent. Hex mode rejects prefixes, spaces, colons, and odd nibbles so a stray formatting character cannot silently change a protocol value. For published test vectors and binary protocol fields — message digests, request bodies from a captured trace, signing keys delivered as raw bytes — hex mode is the safer choice.
Text mode is appropriate when the spec defines the message as a character string and the key as a passphrase that all parties type identically. Note that a human password is rarely a strong HMAC key on its own; the protocol should specify a password-based key derivation function with parameters for salt and iteration count, or it should distribute a generated high-entropy secret through a protected channel.
Use the Calculator for API Signing and Webhooks
Two practical jobs drive most calculator traffic. The first is signing outgoing API requests, where the client concatenates a canonical request string and signs it with a shared secret, then sends the tag in a header. The second is verifying incoming webhooks, where the server receives a payload, recomputes the tag from the raw request body, and compares it to the value the sender provided.
For signing, the calculator is the canonical-string computer: build the exact string the spec defines, paste it as the message, paste the secret as the key, and copy the resulting tag into the header. If the API rejects the signature, the disagreement almost always traces back to the canonical string — line endings, query parameter ordering, or included versus excluded headers — rather than the HMAC arithmetic.
For webhook verification, the calculator is a debugging aid: paste the secret and the raw request body, generate the expected tag, and compare it character-for-character against the value in the signature header. The HMAC Generator limits each decoded field to 1,000,000 bytes, which constrains how large a raw webhook payload can be pasted in. Always use a constant-time comparison on the server so the comparison itself does not leak timing information. The calculator handles the math; the protocol handles the wrapper.
Security Practices That Affect the Calculator Output
Three operational habits change the result the calculator returns, and skipping them turns a correct tag into a useless one:
- Generate high-entropy keys. Independent random bytes of the right length, distributed through a protected channel, are the only durable secret. Reused, derived-from-context, or human-chosen keys make HMAC forgery easier than the hash strength suggests.
- Separate keys by purpose. The key used to sign webhook payloads should not be the same key used to sign user session tokens. If one purpose is compromised, the other remains intact and the rotation is local.
- Rotate after compromise and verify on the server. When a key changes, generate a fresh calculator tag with the new key and have the verifier recompute and compare with a constant-time function. Comparison in code, not in a human eye, is the only acceptable verification.
The calculator itself does not phone home, so it can be used on production secrets without uploading them. That property matters: an HMAC value is only as trustworthy as the environment that produced it, and a local-browser calculator like the HMAC Generator keeps the secret in the current tab while computing the tag.