The three parts of a JWT
A JWT consists of three parts separated by dots: header.payload.signature. Each part is Base64URL encoded, which is why they start with 'eyJ' — that's the Base64URL encoding of '{' (the start of a JSON object).
The header contains the token type (always 'JWT') and the algorithm used to sign it — common values are HS256 (HMAC-SHA256) and RS256 (RSA-SHA256). The payload contains the claims — the actual data being conveyed, like user ID, roles, and expiration time. The signature is a cryptographic value that allows the server to verify the token hasn't been tampered with.
Decoding the header and payload is trivial — anyone can do it because Base64URL encoding is not encryption. The token is not secret. What's secret is the signing key that produces the signature. The signature is what prevents tampering.
- Header: algorithm and token type
- Payload: claims (user data, expiry, issuer)
- Signature: verifies the token hasn't been modified
Common JWT claims and what they mean
JWTs carry claims in the payload. Some are standardized ('registered claims') and others are custom to your application.
The most important registered claims are: iss (issuer — who created the token), sub (subject — usually the user ID), aud (audience — who the token is intended for), exp (expiration time — a Unix timestamp after which the token is invalid), iat (issued at — when the token was created), and nbf (not before — the earliest time the token is valid).
Custom claims carry application-specific data like user roles, email addresses, or permission flags. These are perfectly valid but should not contain sensitive data since the payload can be decoded by anyone who has the token.
Decoding a JWT online
The Irreva JWT Decoder lets you paste a JWT and immediately see the decoded header and payload. It highlights the expiration time and tells you whether the token is currently valid based on the exp claim.
Decoding is purely client-side — the token doesn't leave your browser. This is important if the JWT contains user data or sensitive application information.
Note: decoding shows you the contents of the token. It does not verify the signature — that requires the secret key, which only the server should have. If you need to verify a signature, you need the server-side verification code.
Common JWT issues in the wild
Expired tokens are the most common JWT problem developers encounter. The exp claim is a Unix timestamp. When the current time exceeds exp, the token is expired and the server should reject it. If you're decoding a token and seeing 401 errors, check the exp value first.
Algorithm confusion attacks are a known vulnerability where an attacker changes the header algorithm from RS256 to HS256 and signs the token with the server's public key as the secret. Libraries that don't specify expected algorithms are vulnerable. Always configure your JWT library with a specific expected algorithm.
Never store sensitive data in the JWT payload. The payload is readable by anyone with the token. Store user IDs and roles; never store passwords, SSNs, or other confidential data.