JWT Decoder
Decode and inspect JSON Web Tokens. View header, payload, and expiration status. 100% client-side.
Paste JWT Token
What Is a JWT and Why Should You Care?
A JSON Web Token (JWT) is a compact, URL-safe way of representing claims between two parties. In plain English: it's how most modern web apps handle authentication. When you log in, the server creates a JWT containing your identity and permissions, signs it cryptographically, and hands it back. Every subsequent request includes that token to prove who you are.
A JWT has three parts separated by dots: header.payload.signature. The header tells you the algorithm used. The payload contains the actual claims (user ID, roles, expiration). The signature ensures nobody has tampered with the first two parts.
This decoder splits the token and shows you the header and payload in readable JSON. It runs entirely in your browser — your tokens never leave your device. Perfect for debugging auth issues during development.
JWT Structure Explained
| Part | Encoding | Contains | Example Fields |
|---|---|---|---|
| Header | Base64URL | Token metadata | alg (algorithm), typ (type) |
| Payload | Base64URL | Claims (data) | sub (subject), exp (expiry), iat (issued at) |
| Signature | Binary | Verification hash | HMAC-SHA256 or RSA-SHA256 output |
What this means for you: The header and payload are just Base64URL-encoded JSON — anyone can read them. The signature is the only part that provides security. Never put sensitive data (passwords, credit card numbers) in a JWT payload.
Standard JWT Claims
| Claim | Full Name | Purpose |
|---|---|---|
| iss | Issuer | Who created the token (e.g., auth.myapp.com) |
| sub | Subject | Who the token identifies (usually user ID) |
| aud | Audience | Who should accept this token (e.g., api.myapp.com) |
| exp | Expiration | Unix timestamp when the token expires |
| iat | Issued At | Unix timestamp when the token was created |
| nbf | Not Before | Token is invalid before this time |
| jti | JWT ID | Unique identifier to prevent replay attacks |
Common JWT Debugging Tips
Token expired?
Check the "exp" claim. It's a Unix timestamp — convert it to a human-readable date to see when it expired. If your app gets 401 errors after a while, the token lifetime is likely too short.
Wrong permissions?
Look for "roles", "scope", or custom claims in the payload. If a user can't access a resource, their token might be missing the required role or scope claim.
Signature invalid?
The server's signing key might have rotated, or the token was modified in transit. This decoder doesn't verify signatures — it just reads the payload. Use server-side verification for security.
Never store JWTs in localStorage
localStorage is vulnerable to XSS attacks. Use HttpOnly cookies for auth tokens in production. Session storage is slightly better but still accessible to scripts on the same page.
JWT vs Session Cookies
| Feature | JWT (Stateless) | Session Cookie (Stateful) |
|---|---|---|
| Server storage | None — token is self-contained | Session store (Redis, DB) |
| Scalability | Easy — any server can verify | Needs shared session store |
| Revocation | Hard — token valid until expiry | Easy — delete from store |
| Size | ~800 bytes typical | ~32 byte session ID |
| Best for | APIs, microservices, mobile | Traditional web apps, SPAs |
What this means for you: JWTs shine in distributed systems where multiple services need to verify identity without sharing a database. Session cookies are simpler and more secure for single-server web apps because you can revoke them instantly.
Related Tools
How to use this tool
Paste your JWT token into the input field
Click Decode to view the header and payload
Check the expiration status and claim values
Common uses
- Debugging authentication issues in web apps
- Inspecting token claims and permissions
- Checking token expiration during development
- Verifying JWT structure before API calls
- Understanding OAuth2 and OIDC token contents
Share this tool