About HMAC SHA-256
HMAC SHA-256 combines a secret key with your message to produce a keyed 256-bit signature, printed as 64 hexadecimal characters. Unlike a plain hash, the output cannot be reproduced by someone who does not hold the key, which is what makes it useful for proving that a request or payload came from a trusted source and arrived unaltered.
The most common real use is webhook verification. A service signs the raw request body with a shared secret and sends the signature in a header; you recompute the HMAC over the exact bytes you received and compare. GitHub, Stripe, Slack and many others use precisely this scheme with SHA-256. The same primitive is also the signing step inside an HS256 JSON Web Token and is widely used for API request signing.
Both the key and the message are treated as UTF-8 text here, so if a provider hands you a hex or Base64 secret you should decode it to raw bytes before pasting — an HMAC over the wrong bytes will never match. The computation happens locally through Web Crypto and nothing is transmitted.
How to use HMAC SHA-256
- 1 Paste your secret key into the Secret key field, using the exact value the sender used.
- 2 Paste the message, or the raw request body, into the Message field without reformatting it.
- 3 Compare the 64-character hex signature against the one in the request header or the provider documentation.
Frequently asked questions
My signature does not match the provider's. What usually goes wrong?
The two most common causes are a key delivered in Base64 or hex and pasted verbatim instead of being decoded to bytes, and a message body that was re-serialised so its whitespace or key order changed. Always sign the exact bytes you received.
Is HMAC the same as hashing the message with the key appended?
No. HMAC folds the key into the compression function twice — an inner pad and an outer pad — which defends against the length-extension attacks that a naive key-plus-message hash would be exposed to.
Can I use HMAC SHA-256 to store passwords?
It is better than a bare hash because it requires the key, but it is still a fast function and no substitute for a deliberately slow password-hashing algorithm such as PBKDF2 or Argon2 with a per-user salt.
Does the order of key and message matter?
Yes. Swapping them produces a different signature every time. The key is the secret and the message is the data being signed; the two are not interchangeable.
Free, online, and private
Free to use
HMAC SHA-256 is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How HMAC SHA-256 behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Construction | HMAC over SHA-256, through crypto.subtle.importKey and sign |
| Output | 64 lowercase hex characters, with no separators and no prefix |
| Inputs | a key and a message, both UTF-8 encoded before use |
| Default values | key "secret" and message "Hello world" |
| Empty message | accepted — a keyed digest of the empty string is still produced |
Compiled from the implementation of this tool and checked against it by itoolnet.
What HMAC SHA-256 does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- An empty key is refused by the platform rather than handled here: WebCrypto rejects a zero-length HMAC key with a DataError, so clearing the key box produces an error line instead of a digest, and the wording of that message comes from the browser.
- The digest is shown in hex only. There is no base64 form and no verify mode, so checking a signature that arrived as base64 means converting it yourself and then comparing the two strings to each other.
- Both arguments are treated as text. The key is UTF-8 encoded, so a key that is really binary — bytes read from a file, or a base64 string you forgot to decode — is signed as its printable characters, and the MAC will not match one computed over the raw bytes.
Tested and documented by itoolnet, the team that builds and maintains this site.