HMAC Signature Generator
Compute HMAC signatures with SHA-1/256/384/512 — key and message in, WebCrypto computes locally, hex or base64 out.
>_ USAGE GUIDE
Pick a hash algorithm (SHA-1 / SHA-256 / SHA-384 / SHA-512), enter a key and a message, and the tool computes the HMAC signature in real time via browser WebCrypto, output in hex or base64 — copy it with one click.
HMAC (Hash-based Message Authentication Code) is a keyed hash: it mixes the key and message together and hashes several times, so unlike a plain hash, someone without the key cannot forge the same signature. It is commonly used for API signing — a client computes HMAC over request parameters with a shared key, the server recomputes with the same key and compares, which verifies both that the message was not tampered with and that the request came from a party holding the key.
- Choose the algorithm: match the server's convention, typically SHA-256
- Enter key and message: the shared secret and the content to sign (parameter string, timestamp, etc.)
- Pick an output format: hex or base64, whichever the verification side expects
- Compare: match the result against the server's or a reference implementation to confirm
The key and message are computed locally in your browser and never leave the device, so signing sensitive handshake parameters is safe.
>_ FAQ
Q1 · How is HMAC different from a plain hash like MD5 or SHA-256?
A plain hash digests only the message, so anyone can compute the same value — it proves integrity but not who produced it. HMAC additionally mixes in a secret known only to both parties, so the same message with a different key yields a different signature. HMAC therefore provides both integrity and authentication (anti-forgery), which is why API signing favors HMAC over a bare hash.
Q2 · Why is the output offered in both hex and base64?
The same digest can be encoded in different forms: hex writes each byte as two hexadecimal digits (longer but very common), while base64 is more compact. The choice depends on what the verifying server expects — both sides must use the same encoding to compare. Most specs say something like "HMAC-SHA256, lowercase hex"; follow that.
Q3 · What makes a good HMAC key?
A key should be long and random, ideally at least as long as the hash output (for SHA-256, ≥32 random bytes). Never use a guessable value such as a password or username. The key is shared only between client and server and distributed over a secure channel (e.g. TLS); this tool does not store the key, so closing the page leaves nothing behind.
Q4 · Can HMAC replace encryption?
No. HMAC provides authentication, not encryption — it does not hide the message content, only proves the message is intact and came from the key holder. To also keep content confidential, use symmetric encryption or HTTPS. HMAC usually works alongside encryption (sign after encrypt) for authenticating and anti-tamper protection of API calls.
Q5 · Why does my HMAC result not match an online reference?
HMAC requires the message to be byte-for-byte identical. The usual culprits, in order: the key's encoding interpretation differs — this tool can read the key as UTF-8 text, hex, or base64 (switchable above the key box); payment-callback integrations often use hex keys, and if the two sides interpret the same string differently the results will never match, so check this first. Then: invisible spaces or newlines left in the key or message; a message assembled in the wrong order (for example, parameters not sorted before concatenating); or a difference in hex case or base64 variant. Checking these one by one usually resolves it.