ToolWrenA JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties — most often used for authentication. If you have ever logged into an app and seen a long string of three dot-separated chunks in your network tab, that is a JWT. This guide explains how to read one.
The three parts
A JWT looks like xxxxx.yyyyy.zzzzz — three Base64URL-encoded segments separated by dots:
- Header — the algorithm (e.g.
HS256) and token type. - Payload — the claims (the actual data, such as user id and expiry).
- Signature — a cryptographic signature over the header and payload.
Paste any token into our JWT decoder to see all three parts decoded instantly and privately.
Standard claims you'll see
The payload often contains registered claims with short names: iss (issuer), sub (subject/user), aud (audience), exp (expiry time), iat (issued-at) and nbf (not-before). The time claims are Unix timestamps — seconds since 1 January 1970 — so a value like 1748876543 is a date, not a random number.
Checking expiry
The exp claim tells you when the token stops being valid. Convert it with our Unix timestamp converter, or let the JWT decoder flag expiry for you automatically. An expired token should be rejected by the server even though it still decodes fine.
Decoding is not verifying
Important: decoding a JWT just reads it — it does not prove the token is genuine. Only the server holding the secret (for HS*) or the public key (for RS*/ES*) can verify the signature. Never trust the contents of a token you have only decoded on the client. If you need to create signed tokens for testing, use our JWT generator.
Security tips
Because the payload is only Base64-encoded, never put secrets in a JWT — anyone can read it. Keep tokens short-lived, always validate the signature server-side, and transmit them over HTTPS only.