What is a JWT, and what can you safely learn by decoding it?
A JSON Web Token packages claims as a signed, URL-safe string. Decoding reveals its structure and contents instantly—but decoding is not verification, and anyone can read the payload without a key.
The three segments of a JWT
A JWT is three Base64url-encoded segments joined by dots:
header.payload.signature. The header names the signing
algorithm, the payload carries the claims, and the signature lets a
verifier confirm the token was produced by a holder of the secret or
private key.
Registered claims worth knowing
Standard claim names defined by RFC 7519.
| Claim | Meaning | Why it matters |
|---|---|---|
iss | Issuer of the token | Lets verifiers reject tokens from unexpected sources |
sub | Subject—the principal the token describes | Usually the user or service identifier |
exp | Expiry time in Unix seconds | Tokens must be rejected after this moment |
nbf | Not-before time in Unix seconds | Tokens are invalid before this moment |
aud | Intended audience | Stops tokens issued for one service being replayed at another |
Decoding vs verifying
Read-only inspection
Base64url is plain encoding. Decoding shows you what a token claims, which is invaluable for debugging expired sessions or wrong audiences.
Cryptographic proof
Only a server holding the key can check the signature. Never trust decoded client-side output for authorization decisions.
Keep tokens short-lived
Combine brief expiry windows with refresh tokens so a leaked access token has limited value.