JWT Decoder
Paste a JWT to decode its header, payload, and inspect claims. Everything runs in your browser — your token never leaves.
How it works: Paste a JWT token below to instantly decode its header and payload. The tool highlights expiration status and displays all claims in a readable format. No data is sent to any server.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"email": "john@example.com",
"role": "admin",
"iat": 1773346245,
"exp": 1773436245,
"iss": "https://auth.example.com",
"aud": "https://api.example.com"
}| Claim | Value |
|---|---|
| sub | 1234567890 |
| name | John Doe |
| john@example.com | |
| role | admin |
| iat | 1773346245 (2026-03-12T20:10:45.000Z) |
| exp | 1773436245 (2026-03-13T21:10:45.000Z) |
| iss | https://auth.example.com |
| aud | https://api.example.com |
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It consists of three parts separated by dots: header, payload, and signature. The header specifies the algorithm used, the payload contains the claims (data), and the signature verifies the token's integrity. JWTs are widely used for authentication and authorization in web APIs.
JWT Structure Explained
Each part of a JWT is Base64URL-encoded JSON. The header typically contains the algorithm (HS256, RS256) and token type. The payload contains claims like sub (subject), iat (issued at), exp (expiration), and custom data. The signature is created by signing the header and payload with a secret or private key.
Common JWT Claims
Standard claims include: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims can contain any JSON data like user roles, permissions, or profile information. Always validate the exp claim to check if a token has expired.
Security Considerations
- Never store sensitive data in JWT payloads — they are encoded, not encrypted
- Always verify signatures on the server side
- Use short expiration times and refresh tokens
- Prefer RS256 over HS256 for public APIs
- Never expose your signing secret in client-side code
- Use HTTPS to prevent token interception