JWT HS256 Signature Verifier | Confirm a Token's Signature With Your Secret

Recompute the HMAC-SHA-256 of header.payload with your shared secret and compare the result against the token's third segment. The signature check reports one of three states — valid, mismatch, or a non-HS256 alg — while the header and payload are decoded and shown as formatted JSON.

💡 About this tool

The hard part of JWT debugging isn't reading the token — it's knowing whether the signature actually checks out. Plain decoders open the base64url segments and show you the claims, but a decoded payload tells you nothing about whether the signature is correct. That needs a recomputation with the secret.

This tool takes the header.payload portion, runs HMAC-SHA-256 over it with the secret you supply, base64url-encodes the MAC, and string-compares it to the signature at the end of the token. A match prints valid; any difference prints mismatch; a header whose alg is anything other than HS256 is rejected as unsupported alg. Change one character of the secret or tamper with the payload and the verdict flips, which makes it easy to isolate which value is breaking the signature.

Scope is HS256 (the HMAC family) only. RS256 and ES256 are public-key and elliptic-curve schemes verified with a key pair rather than a shared secret, so they fall outside this tool; when the alg is one of those, you get the unsupported-alg state instead of a misleading result.

🧐 Frequently Asked Questions

Q. How is this different from a decoder? A decoder base64url-decodes the header and payload and displays them. It never recomputes the signature. This tool runs the HMAC and tells you whether the signature matches.

Q. Why does my token come back as mismatch? Usually the wrong secret, an edited payload, a truncated copy that dropped the trailing characters, or a misplaced . between segments. Revert one change at a time to find the culprit.

Q. What form does the secret take? Enter the HS256 shared secret as the same UTF-8 string the signing side uses. If your stack stores the key base64-encoded, paste the exact string the issuer passes as the key rather than re-encoding it.

Q. Does it check expiry (exp)? No — it only checks signature equality. Claim validation such as exp and nbf is out of scope, so read those from the decoded payload JSON yourself.

Q. What about a token with alg set to none? Any alg other than HS256, including none, returns unsupported alg. Accepting none is a known vulnerability, so verifiers should reject it outright.

📚 Fun Facts

The "HS" in HS256 stands for HMAC using SHA-256, and the JWA spec (RFC 7518, §3.1) lists it as the one mandatory-to-implement algorithm — every conforming JWT library must support it. A single shared secret signs and verifies, which is why HS256 is so common in small services, but it also means the issuer and verifier hold the same key: leak it and anyone can mint valid tokens. One detail that trips people up is that the signature is computed over the signing input — the header and payload joined by a . — so the third segment is a MAC derived from that string, not the payload itself.

The JWT and secret you paste stay inside your browser and are never sent to a server; the HMAC runs locally through the standard Web Crypto API.