What lives inside a JWT
A JSON Web Token has three Base64URL parts: a header naming the algorithm, a payload of claims (who the token is for, when it expires), and a signature. Anyone can read the first two — they're encoded, not encrypted — which is why you should never put secrets in the payload.
Decode vs verify
Decoding just reveals the claims; it says nothing about whether the token is genuine. Verification recomputes the signature with your secret and checks it matches, proving the token hasn't been altered. This tool does both, side by side.
Why local signing matters
Your signing secret is the key to forging valid tokens, so pasting it into a server-side tool is risky. Here, generation and verification run entirely in your browser — the secret is used in memory and never transmitted.
- 01
- Decode header, payload & a full claims table
- 02
- HS256, HS384 & HS512 signing and verification
- 03
- Live signature verification with your secret
- 04
- Expiry detection + human-readable iat/exp/nbf
- 05
- Generate signed tokens live as you type
- 06
- One-click expiry injection (1h, 24h, 7d)
- 07
- Zero-server — keys never leave your browser


