1. JWT anatomy you need to know
A JSON Web Token consists of three dot‑separated parts: Header, Payload, and Signature. The first two are JSON objects that are base64url‑encoded. The Signature is the HMAC (or RSA/ECDSA) of the string "header.payload" using the secret key. For HS256 the algorithm is HMAC‑SHA256.
2. Build the signing input
Do **not** re‑encode the already encoded header or payload. Take the exact strings that appear before the last dot in the token. For the example token the signing input is: ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ ```
3. Compute HMAC‑SHA256 with an online calculator
Use any HMAC‑SHA256 generator that accepts a raw key (not base64). Paste the signing input as the *message* and the secret `hONPMX3tHWIp9jwLDtoCUwFAtH0RwSK6` as the *key*. The tool will output a binary hash; you must base64url‑encode that hash to obtain the JWT signature.
**Step‑by‑step with free tools**: 1. Open a HMAC‑SHA256 calculator (e.g., https://www.tools4noobs.com/online_tools/hmac/). 2. Enter the signing input in the *Message* field. 3. Enter the secret in the *Key* field (plain text, no padding). 4. Click *Generate* – you receive a hex string. 5. Convert the hex string to raw bytes (many tools have a *Hex → Base64* converter). 6. Finally, base64url‑encode the raw bytes (replace `+` with `-`, `/` with `_`, and strip `=` padding).
4. Compare the computed signature
The token you are checking ends with `wDQ2mU5n89f2HsHm1dluHGNebbXeNr748yJ9kUNDNCA`. If the base64url‑encoded hash you derived matches this exact string, the signature is valid. Any mismatch means either the secret, the signing input, or the encoding step is wrong.
5. Quick command‑line verification (optional)
If you have access to a terminal, the same process can be reproduced with OpenSSL, which eliminates the need for a web UI. ```bash # 1. Prepare the signing input (copy‑paste exactly) INPUT='eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ' # 2. Compute HMAC‑SHA256 (binary output) SIG=$(printf "%s" "$INPUT" | openssl dgst -sha256 -hmac 'hONPMX3tHWIp9jwLDtoCUwFAtH0RwSK6' -binary) # 3. Base64url‑encode the binary signature ENC=$(printf "%s" "$SIG" | base64 | tr '+/' '-_' | tr -d '=') # 4. Show the result echo $ENC ``` The printed value should be identical to the token's third part.
**Common pitfalls**: double‑encoding the header/payload, using a base64‑encoded secret, or forgetting to strip padding from the final base64url string.
Takeaway: Validate a JWT signature by recreating the exact signing input, hashing it with HMAC‑SHA256 using the plain secret, and base64url‑encoding the result.
People also ask
Do I need to base64url‑encode the secret before HMAC?
No. For HS256 the secret is used as raw UTF‑8 bytes. Encoding it changes the key and breaks verification.
Why does the JWT site sometimes show a different signature?
The debugger may treat the secret as base64‑encoded when the *Base64‑encode secret* option is checked. Ensure the option is off to match manual calculation.
Can I verify RSA‑signed JWTs without code?
Yes, but you need a public key and a tool that supports RSA‑SHA256 verification, such as the OpenSSL `dgst -sha256 -verify` command or an online RSA verifier.
Inspired by a public discussion on Stack Overflow. This article is an original explanation for learners.