JWT decoder
JSON Web Tokens are three Base64url segments: header.payload.signature. Paste a JWT to read algorithm (alg), issuer (iss), subject (sub), and expiration (exp) without sending the token to a server. This decoder does not verify signatures — use your app’s secret or JWKS for that.
JWT token
Output
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "Ada",
"iat": 1516239022
}
}
How to decode a JWT
1. Paste the JWT string (eyJ... format).
2. Read decoded header JSON (typ, alg).
3. Read payload claims (sub, exp, roles).
4. Check exp against current time — expired tokens fail API auth.
JWT inspection examples
Debug 401 Unauthorized
Decode access token — exp may be in the past due to clock skew or short TTL.
Inspect OAuth id_token
View email and name claims returned from identity provider.
Review test fixture
Confirm HS256 test token has role:admin claim before integration test.
When to decode JWTs
• When debugging auth in development with test tokens.
• When learning JWT structure and standard claims.
• When verifying payload before implementing RBAC checks.
Security limits
• Do not paste production tokens with live privileges into untrusted websites — this tool is local but practice caution.
• When you need signature verification — use server-side crypto with secret/public key.
• When token is encrypted JWE — different format than three-part JWS.
Standard registered claims
iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID). Custom claims like roles or tenant_id are app-specific.
Signature algorithms
HS256 uses shared secret; RS256 uses RSA public/private key pair. Public keys published via JWKS URL for verification.
Clock skew
APIs often allow 30–60 second leeway on exp/nbf. If valid in decoder but API rejects, check server clock and timezone.
Never trust payload alone
Client-side decode for UI hints only — authorization decisions must verify signature on server every request.
Frequently asked questions
What are the three JWT parts?
Header (algorithm & type), payload (claims), signature (verification). Separated by dots.
Does decoding validate the token?
No — anyone can decode payload; signature proves integrity and issuer.
What is exp claim?
Unix timestamp seconds when token expires. Compare with current UTC time.
None algorithm attack?
Servers must reject alg:none — decoder may still show header for audit.
Sensitive data in payload?
JWT payload is Base64 not encrypted — never put passwords or PII unnecessarily.
Local processing?
Yes — token parsed in browser.
Refresh vs access token?
Both are JWTs often — decode each to see scopes and lifetimes differ.