JWT Token
Decoded Header
Decoded Payload
Common Claims
About the JWT Decoder
A JSON Web Token (JWT) is the self-contained credential format powering modern authentication: three Base64URL segments separated by dots — header, payload, signature. The header names the signing algorithm; the payload carries claims (who you are, what you may do, when it expires); the signature lets the server verify none of it was altered. Development constantly requires reading those middle segments, and Base64 is unreadable by design.
This decoder splits any JWT and renders its header and payload as formatted JSON with colour-coded claims. Standard claims (iss, sub, aud, exp, iat, nbf, jti) appear with plain-language explanations, and the exp claim shows whether the token is currently valid and how long it has left. Decoding is purely local — even so, treat tokens as passwords and clear the page after use.
One boundary the tool is explicit about: decoding shows what a token *says*, not whether it is *true*. Only the signature — verified server-side with the secret or public key — proves authenticity. A decoded token with valid-looking claims can still be forged.
How to use the JWT Decoder
- 1 Paste the full JWT (all three dot-separated segments) into the input.
- 2 Header and payload render instantly as readable JSON.
- 3 Check the expiry panel: exp is translated into a date and remaining validity.
- 4 Inspect claims against expectations — issuer, audience, subject, and custom scopes.
Key features
Instant three-part split
Header, payload, and signature separated and identified automatically.
Claim explanations
Standard registered claims annotated with their meanings and typical values.
Expiry intelligence
exp/iat/nbf rendered as human dates with live valid/invalid status.
Local-only decoding
Tokens never leave the browser; paste production credentials without logging risk.
Who uses the JWT Decoder?
- Debugging 401s: checking which issuer, audience, and scopes the rejected token carried.
- Verifying token lifetime math between client clocks and server policy.
- Learning authentication flows — seeing exactly what an access token contains.
- API integration: confirming custom claims your provider promised are present.
- Security reviews inspecting algorithm headers (and flagging the alg:none red flag).
Tips and best practices
- exp and iat are Unix seconds. Multiply by 1000 in JavaScript before Date comparisons.
- A token’s payload is readable by anyone with the string — never place passwords or card data in claims.
- Short-lived access tokens (5–60 min) with refresh tokens beat long-lived tokens on every threat model.
- If the header says HS256, signature verification needs the shared secret server-side; RS256 needs the provider’s public key (often at a /.well-known/jwks.json endpoint).
- Reject tokens where alg is none or where the audience does not match your API — both are classic vulnerability findings.
- Clock skew between services breaks validation quietly; allow 30–60 seconds of leeway in production checks.
Frequently asked questions
No. Parsing happens entirely in your browser. Still, treat pasted tokens as sensitive — close the tab when done.
No — it decodes and displays content. Signature verification requires the secret or public key and must happen in trusted backend code.
Base64URL(header).Base64URL(payload).Base64URL(signature). The first two are plain JSON once decoded; the third is the cryptographic seal over them.
iat: issued-at time. exp: expiry after which the token is invalid. iss: the issuer who created it. aud: the intended recipient — an API should reject tokens whose aud does not match itself.
The exp claim is earlier than your device’s current time. Refresh tokens exist precisely to obtain new access tokens when this happens.