JWT Decoder
Decode and inspect JSON Web Tokens. 100% client-side — your tokens never leave your browser.
Related Tools
What is a JSON Web Token (JWT)?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519 for securely transmitting claims between parties. JWTs are widely used for authentication (proving identity), authorization (granting access), and secure information exchange in modern web APIs, mobile apps, and microservice architectures.
JWT Structure (header.payload.signature)
A JWT consists of three Base64URL-encoded parts joined by dots: the header (algorithm and token type, RFC 7515), the payload (claims about the user or session, RFC 7519), and the signature (HMAC or public-key signature over header + payload). The structure is tamper-evident: any modification to header or payload invalidates the signature.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF... └────header───┘ └─────payload─────┘ └────signature─────┘
Why Decode JWTs Client-Side?
JWTs often contain sensitive information — user IDs, email addresses, roles, permissions, or even PII. Pasting a production JWT into a remote decoder leaks all of that to a third-party server, where it may be logged, stored, or analyzed. This tool processes everything in your browser using atob and JSON.parse — the token never leaves your device.
How to Use
- Paste your JWT token in the JWT Token input field. The token starts with
eyJ(Base64 of{") followed by two more dot-separated parts. - Click Decode, or press
Ctrl+Enter(Cmd+Enteron macOS) to instantly decode. - Inspect the HEADER (algorithm, type) and PAYLOAD (claims) blocks. The signature is shown as opaque base64 — verifying it requires the issuer's secret/public key.
- Check token expiration via the
expclaim (Unix timestamp). Expired tokens are flagged automatically. - Click Copy next to any section to copy its JSON to clipboard.
Standard JWT Claims (RFC 7519)
The JWT spec defines seven standard registered claims. Custom claims (any other field name) are also allowed, but should avoid collision with public registered names.
| Claim | Name | Description |
|---|---|---|
| iss | Issuer | Who issued the token (your auth server) |
| sub | Subject | User ID the token is about |
| aud | Audience | Intended recipient (your API) |
| exp | Expiration | Unix timestamp; token invalid after this |
| nbf | Not Before | Token invalid before this time |
| iat | Issued At | When the token was generated |
| jti | JWT ID | Unique token ID (for revocation lists) |
Common signing algorithms
- HS256/HS384/HS512 — HMAC with SHA-2. Symmetric: same secret signs and verifies. Fast, simple, but requires sharing the secret.
- RS256/RS384/RS512 — RSA signatures. Asymmetric: private key signs, public key verifies. Standard for OAuth/OIDC at scale.
- ES256/ES384/ES512 — ECDSA on NIST curves. Smaller keys/signatures than RSA at equivalent security. Modern default.
- EdDSA (Ed25519) — Edwards-curve signatures. Fastest verification, deterministic, no parameter pitfalls. Recommended for new systems.
Common JWT Pitfalls
1. The alg: none vulnerability
The original JWT spec allowed "alg": "none" for unsigned tokens. Multiple libraries accepted this without checking, letting attackers forge any token by stripping the signature. Modern libraries reject none by default, but always verify your library does. Configure an explicit algorithm allowlist on your server.
2. Algorithm confusion (HS256/RS256)
If your code accepts both HMAC and RSA, an attacker can sign a token with HS256 using your public RSA key as the HMAC secret. Always pin the expected algorithm — never "auto-detect" from the header.
3. JWTs can't be revoked easily
Stateless JWTs are valid until exp. Logout, account lock, or password change won't invalidate existing tokens without a server-side revocation list (Redis, deny-list table) or short token lifetimes (~15 minutes) backed by long-lived refresh tokens.
4. Storing JWTs in localStorage = XSS risk
Any XSS can read localStorage and steal the token. Use HttpOnly, Secure, SameSite=Lax cookies for browser apps. Mobile apps should use platform-secure storage (Keychain/Keystore).
5. Sensitive data in payload
The payload is Base64-encoded, not encrypted. Anyone with the token can decode and read all claims. Never put passwords, credit card numbers, or unhashed PII in the payload. If you need confidentiality, use JWE (encrypted JWT, RFC 7516).
FAQ
Does this tool verify the JWT signature?
No. This tool only decodes and displays the token contents. Signature verification requires the secret key or public key, which should never be shared with a web tool. Use your server-side library (jsonwebtoken, jose, PyJWT, etc.) for production verification.
Is it safe to paste my production JWT here?
Yes. Everything runs in your browser — verify with DevTools → Network: no requests are made when decoding. The token never leaves your device. Still, treat any leaked JWT like a password — rotate it if you suspect exposure.
Why does the signature look like garbage?
The signature is raw cryptographic output (HMAC or RSA/ECDSA), Base64URL-encoded. It is meant to be opaque — only useful for verification, not human inspection. The header and payload are JSON, but the signature is binary.
What's the difference between JWT and JWS / JWE?
JWS (RFC 7515) is the signature mechanism — what most JWTs actually are. JWE (RFC 7516) is encrypted JWT, using authenticated encryption (e.g., AES-GCM) so payload contents are confidential. A "JWT" is always a JWS or JWE serialization with a JSON payload.
How long should JWT lifetimes be?
Industry consensus: access tokens 5–60 minutes (because they can't be revoked easily), backed by refresh tokens valid days to weeks stored server-side and rotatable. Auth0 default is 24 hours; AWS Cognito is 1 hour; Google OIDC is 1 hour.
Are JWTs the same as session cookies?
No. Session cookies are opaque IDs that point to server-side state. JWTs are self-contained — the server can verify them without a database lookup. Trade-off: JWTs are stateless and scale horizontally easily, but harder to revoke and contain more data per request.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.
📖 Related Guides
JWT Anatomy — Header, Payload, Signature
Understand JWT structure, claims, and signing algorithms. Security best practices.
URL Encoding — When to Use What
encodeURI vs encodeURIComponent vs escape. Query strings, paths, and reserved characters.
Hash Algorithms — MD5, SHA-1, SHA-256, bcrypt
When to use each hash function. Security comparison and password storage best practices.