If you’ve ever stared at a JWT token like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIx... and had no idea what’s inside it, you’re not alone. JWT tokens are base64url-encoded by design — which makes them compact but completely unreadable by humans. Our free JWT Decoder solves this instantly: paste any token and see its full contents in a clean, structured view within seconds.
What Is a JWT Token?
JWT stands for JSON Web Token — an open standard (RFC 7519) for securely transmitting information between parties as a compact, self-contained JSON object. JWTs are the backbone of modern authentication: when you log in to almost any web application, you receive a JWT that proves your identity for every subsequent API request.
A JWT has three parts separated by dots:
- Header — specifies the token type and signing algorithm (HS256, RS256, ES256, etc.)
- Payload — contains the actual claims: user ID, email, roles, expiry, issuer, and any custom data
- Signature — cryptographic proof that the token was issued by a trusted source and has not been tampered with
Each part is independently base64url-encoded, which is why JWTs look like random strings. They are not encrypted by default — the header and payload are readable by anyone who has the token. Only the signature requires the secret key to verify.
How to Decode a JWT Token
Using the owndevz JWT Decoder is straightforward:
- Copy your JWT token from your app, browser DevTools, Postman, or logs
- Paste it into the input box on the decoder page
- The token is decoded instantly as you type — no button press needed
- View the header, payload, and signature in separate colour-coded sections
- Check the Token Summary for algorithm, expiry status, issuer, and subject
- Inspect every claim in the Claims Inspector table with descriptions
Key Features of Our JWT Decoder
- ⚡ Instant decode as you type — no button press required
- 🌟 JWT colour bar — visual representation of header/payload/signature proportions
- ❓ Expiry detection — shows VALID, EXPIRING SOON, or EXPIRED with exact time
- 📊 Token Summary cards — algorithm badge, expiry status, issued at, expires at, issuer, subject
- 📄 Claims Inspector — every claim explained with human-readable timestamps for exp/iat/nbf
- 🌟 JSON syntax highlighting — keys, strings, numbers, and booleans in distinct colours
- 📋 Copy individual sections — copy header, payload, or signature separately
- 🔒 100% client-side — your token never leaves your browser
- 📄 4 sample tokens — Basic, Auth+Roles, Expired, RS256
- 🔗 URL param support — share a pre-loaded token via ?token=xxx
What Are JWT Claims?
Claims are statements about the subject of the token — typically the authenticated user. The JWT specification defines several standard claims that have specific meanings:
- iss (Issuer) — identifies who issued the token, usually an auth server URL
- sub (Subject) — the principal that is the subject of the JWT, usually a user ID
- aud (Audience) — identifies the recipients that the JWT is intended for
- exp (Expiration Time) — the time after which the JWT must not be accepted for processing
- nbf (Not Before) — the time before which the JWT must not be accepted
- iat (Issued At) — the time at which the JWT was issued
- jti (JWT ID) — a unique identifier for the JWT, used to prevent replay attacks
Beyond these standard claims, applications add custom claims like user roles, email, permissions, subscription tier, organisation ID, and anything else the application needs to know about the authenticated user.
JWT Signing Algorithms Explained
The alg field in the JWT header tells you how the token was signed. Understanding algorithms helps you debug authentication issues:
- HS256 / HS384 / HS512 — HMAC with SHA-256/384/512. Uses a single shared secret key. Simple and fast, common in internal applications.
- RS256 / RS384 / RS512 — RSA signature with SHA-256/384/512. Uses a public/private key pair. The private key signs, the public key verifies. Used in OAuth 2.0 and enterprise SSO.
- ES256 / ES384 / ES512 — ECDSA with P-256/P-384/P-521 curves. Smaller keys than RSA for equivalent security. Increasingly used in modern APIs.
- none — No signature. Never accept tokens with alg: none in production — this is a well-known security vulnerability.
Is It Safe to Decode a JWT Online?
This is an important question. JWT tokens often contain user data like email addresses, user IDs, and roles. Our decoder is 100% client-side — all decoding happens in your browser using JavaScript. Your token is never sent to any server, never logged, and never stored anywhere.
That said, you should still be careful with production tokens in general. If a JWT contains sensitive PII or is a long-lived admin token, treat it like a password. For debugging in production, prefer using short-lived tokens or tokens with minimal claims.
Common JWT Debugging Scenarios
Token is expired
The most common JWT issue. Our decoder shows the exact expiry time in both Unix timestamp and human-readable format, plus how long ago it expired. Check the exp claim and compare with iat to understand the token lifetime.
Wrong audience or issuer
If your API is rejecting a valid-looking token, check the aud (audience) and iss (issuer) claims. These must match exactly what your API expects. Our decoder shows both in the Token Summary section for quick verification.
Missing claims
If your app crashes because it can’t find a claim it expects, the Claims Inspector table shows every claim present in the token. Compare against what your code expects and you’ll immediately see what’s missing.
Wrong algorithm
If your signature verification is failing, check the alg claim in the Header section. If the algorithm doesn’t match what your verification library expects, the signature check will always fail regardless of whether the key is correct.
Decode Your JWT Now
Stop guessing what’s inside your JWT tokens. Open the free JWT Decoder, paste your token, and get full visibility into the header, payload, claims, and expiry status in under a second. No account required, no data sent to servers, completely free.
