How to Use the JWT Decoder

Paste your JWT token — a JWT looks like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Read the decoded header — shows the algorithm (alg) and token type (typ). Common algorithms: HS256 (HMAC-SHA256), RS256 (RSA-SHA256).
Read the decoded payload — the claims: sub (subject/user ID), iat (issued at), exp (expiry), and any custom claims.
Check expiry — the tool converts the exp timestamp to a human-readable date so you can see if the token is still valid.
Verify structure — the tool validates the JWT format and alerts you if the token is malformed or expired.

⚠️ Security reminder: This tool decodes JWT payloads but CANNOT verify the signature without the secret key. A decoded JWT shows the claims, but you cannot trust those claims without signature verification. Never trust a JWT's claims in your application code without verifying the signature using the correct secret or public key.

Understanding JSON Web Tokens

🔑 JWT Structure

Three Base64url-encoded parts separated by dots. Header: {alg: 'HS256', typ: 'JWT'}. Payload: the claims (user ID, roles, expiry). Signature: HMAC or RSA signature of header.payload using the secret key. Only the signature depends on the secret — header and payload are readable by anyone.

📋 Standard Claims

iss (issuer): who issued the token. sub (subject): who the token is about (usually user ID). aud (audience): intended recipient. exp (expiration): Unix timestamp when token expires. iat (issued at): when token was created. nbf (not before): earliest valid time. jti (JWT ID): unique token identifier for revocation.

🔐 HS256 vs RS256

HS256 (HMAC-SHA256): symmetric — same secret key signs and verifies. Simple but the secret must be shared between issuer and verifier. RS256 (RSA-SHA256): asymmetric — private key signs, public key verifies. Server publishes public key; anyone can verify tokens without the private key. RS256 is preferred for distributed systems.

⏰ Token Expiry

JWTs should have short expiry times (15 minutes to 24 hours depending on security requirements). Short expiry limits damage if a token is stolen. Use refresh tokens (longer-lived, stored securely) to obtain new access tokens without re-login. The refresh token pattern is the standard for balancing security and user experience.

🚫 JWT Revocation Challenge

JWTs are stateless — the server doesn't store them. Revoking a JWT before expiry requires either a token blocklist (defeats some stateless benefits) or short expiry with refresh token rotation. Token rotation: each use of a refresh token issues a new refresh token and invalidates the old one — providing limited revocation capability.

🛡️ Common JWT Vulnerabilities

Algorithm confusion: if the server accepts 'alg: none', attackers can forge tokens. Always specify and enforce the expected algorithm. Weak secrets: HS256 with short secrets are brute-forceable. Use 256+ bit secrets. Storing in localStorage: vulnerable to XSS. Prefer httpOnly cookies. Not validating claims: always check exp, iss, and aud.

JWT in Authentication Systems

Stateless authentication flow

1. User logs in with credentials. 2. Server verifies credentials, generates JWT signed with secret. 3. Server returns JWT to client. 4. Client stores JWT (localStorage, sessionStorage, or httpOnly cookie). 5. Client includes JWT in Authorization header: 'Bearer eyJ...' for each request. 6. Server verifies signature and extracts claims — no database lookup needed. This stateless verification scales horizontally without shared session storage.

JWT vs sessions

Traditional sessions store a session ID cookie, with session data in server-side storage (database, Redis). JWTs store all information client-side. Sessions advantages: instant revocation, smaller cookie, no sensitive data exposure. JWT advantages: stateless scaling, works across domains (CORS), no shared storage needed. For most web applications, sessions (especially with Redis) are simpler and more secure. JWTs shine in microservices and API authentication where statelessness is essential.

Debugging authentication with JWT decoder

The most common debugging use: pasting a JWT from an API request to verify the claims being sent. Common issues discovered: token expired (exp in the past), wrong audience (aud doesn't match), wrong user ID (sub is unexpected value), missing required claims. This decoder shows all claims instantly without needing to write decode code or fire up a debugger. Essential tool for any developer working with JWT-based auth systems.

🔑 JWT security checklist: Always verify signature before trusting claims ✓. Enforce specific algorithm (reject 'none') ✓. Validate exp, iss, aud claims ✓. Use short expiry (15 min to 1 hour for access tokens) ✓. Store tokens in httpOnly cookies for web apps ✓. Use 256-bit minimum secret for HS256 ✓. Implement refresh token rotation ✓. These practices prevent the most common JWT security vulnerabilities.

Frequently Asked Questions

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and data exchange. It consists of three Base64URL-encoded parts: Header (algorithm), Payload (claims/data), and Signature — separated by dots.

Is JWT decoding safe?

Decoding is safe — anyone with the token can decode the header and payload, as they are simply Base64-encoded (not encrypted). The signature is what ensures integrity. Never put sensitive data like passwords in a JWT payload.

What is JWT signature verification?

This tool decodes the header and payload but does NOT verify the signature. Signature verification requires the secret key (HMAC) or public key (RSA/EC). Always verify signatures server-side before trusting token claims.

What are JWT claims?

Claims are the payload data: iss (issuer), sub (subject/user ID), aud (audience), exp (expiry timestamp), iat (issued at), nbf (not before). Custom claims can contain any data. The exp claim is checked here to show if the token has expired.

What does 'token expired' mean?

The exp (expiration) claim is a Unix timestamp. If the current time is past that timestamp, the token is expired. Expired tokens should be rejected by the server. Users typically need to log in again to get a fresh token.