How to Decode a JWT and Inspect Its Claims Safely
Quick Answer
A JWT is three Base64URL strings joined by dots: header.payload.signature. Decode the header and payload with Base64URL decoding to inspect claims — but decoding only reads the data, it does not verify authenticity. Always verify the signature on the server before trusting any claim. Use our JWT Decoder to inspect tokens in your browser.
Introduction
A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe token format used for authentication and authorization. It has three Base64URL-encoded parts separated by dots: header.payload.signature. The header describes the algorithm, the payload carries claims (user id, roles, expiry), and the signature proves the token was issued by a trusted party. Crucially, the header and payload are encoded, not encrypted — anyone can read them.
Step by Step
-
Split the token into three parts
A JWT looks like xxxxx.yyyyy.zzzzz. Split on the dot character to get the header (part 0), payload (part 1), and signature (part 2). If there are not exactly three parts, the token is malformed.
-
Base64URL-decode the header
The header is a Base64URL-encoded JSON object like {"alg":"HS256","typ":"JWT"}. Base64URL uses - and _ instead of + and / and omits padding. Decode it, then JSON.parse to read the algorithm and type. Our JWT Decoder does this automatically.
-
Base64URL-decode the payload (claims)
The payload is a JSON object of claims. Registered claims include iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not-before), iat (issued-at), and jti (token id). Private claims are application-specific (e.g. role, email). Decode and inspect, but do not trust until verified.
-
Check the expiry and not-before claims
exp and nbf are Unix timestamps (seconds). If the current time is past exp, the token is expired and must be rejected. If the current time is before nbf, the token is not yet valid. Check these client-side for UX, but enforce them server-side for security.
-
Verify the signature on the server (never client-side)
The signature is HMAC-SHA256(secret, header.payload) for HS256, or RSA/ECDSA signature for RS256/ES256. Verification requires the secret or public key, which must never reach the browser. Use a library like jsonwebtoken (Node) or jose to verify — never write your own crypto.
Examples
A typical JWT (three parts)
Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
Output: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Decoded payload with standard claims
Input: Payload of a real auth token
Output: {"sub":"user-42","iss":"firetools.online","exp":1767229200,"iat":1767225600,"role":"admin"}
Expired token detection
Input: exp: 1609459200 (2021-01-01) checked at 2026-08-28
Output: Token is expired — current time (1767225600) > exp (1609459200). Reject and prompt re-login.
Common Problems
- Treating decode as verify: anyone can craft a JWT with any claims and a fake signature. Decoding reads the payload but proves nothing. Always verify the signature with the secret/public key on the server before trusting claims.
- Using 'none' algorithm: the JWT spec allows alg: none for unsecured tokens. If your verifier accepts alg: none, an attacker can forge tokens. Configure your library to reject none and whitelist expected algorithms.
- Storing JWTs in localStorage: XSS can read localStorage and exfiltrate tokens. Prefer httpOnly, Secure, SameSite=Strict cookies for session tokens, or short-lived in-memory tokens with a refresh-token cookie.
- Not checking exp/aud/iss: a stolen token is valid until it expires. Always check exp (expiry), aud (intended audience), and iss (issuer) on every request to prevent token replay across services.
Tips
- Use short-lived access tokens (15 minutes) plus long-lived refresh tokens — this limits the window if an access token is stolen.
- Prefer RS256 (asymmetric) over HS256 (symmetric) when multiple services verify tokens: each service gets the public key, and only the issuer has the private key.
- Use our JWT Decoder during development to inspect what the server is issuing — it shows the decoded header, payload, and a human-readable claim summary without sending the token anywhere.
- Never put sensitive data (passwords, PII) in a JWT payload — it is Base64-encoded, not encrypted, and anyone who intercepts the token can read every claim.