How to decode a JWT safely, and check its signature

What’s inside a JWT

Take the token apart at the dots. The header says how it was signed ("alg": "HS256"); the payload holds the claims: who it’s about (sub), who issued it (iss), who it’s for (aud), when it was issued (iat) and when it expires (exp), as Unix timestamps. The signature proves the first two weren’t changed.

Why pasting tokens into websites is risky

A live access token is a key: whoever has it can call the API as that user until it expires. Many decoder sites are safe, but you can’t easily tell which ones log what you paste. Use a decoder that runs entirely in your browser, and prefer test tokens or expired ones when you can.

Dev Tools’ JWT decoder runs on your device with no server involved; you can turn off your connection and it still works. Its share links even warn you before a token goes into a link.

Decode and check a token

1. Paste the token (a leading “Bearer ” is fine).
2. Read the header and claims, with the times shown as dates and how long until it expires.
3. Check the signature: paste the shared secret for HS256, HS384 or HS512, or the public key (PEM or JWK) for RS, PS and ES algorithms.
4. Make a test token with your own claims and secret, to try your API’s handling of expired or wrong-audience tokens.

Mistakes to look for

• "alg": "none". An unsigned token. A server must never accept it.
• No exp. A token that never expires is a key that never changes.
• The wrong key type. An RS256 token checked as HS256 with the public key as the “secret” is a classic attack; servers should fix the algorithm, not read it from the token.
• Clock skew. A token “not valid yet” often means the issuing server’s clock is ahead.