AI JWT Decoder — Inspect and Debug JSON Web Tokens

JSON Web Tokens are everywhere in modern authentication. Every API call with a Bearer token, every OAuth flow, every single sign-on session relies on JWTs to carry identity and authorization data. But when authentication breaks, the first thing you need to do is look inside the token to understand what went wrong.

An AI JWT decoder instantly splits a token into its three parts, decodes the Base64URL-encoded header and payload, formats the JSON for readability, checks expiration timestamps, and highlights potential security issues.

Anatomy of a JWT

A JWT consists of three Base64URL-encoded parts separated by dots: the header, the payload, and the signature. Each part serves a distinct purpose:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikpv
aG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

// Decoded header:
{ "alg": "HS256", "typ": "JWT" }

// Decoded payload:
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

The Header

The header declares the token type and the signing algorithm. The most common algorithms are HS256 (HMAC with SHA-256, symmetric) and RS256 (RSA with SHA-256, asymmetric). The algorithm choice affects how you verify the signature and has significant security implications.

The Payload

The payload contains claims, which are statements about the user and metadata. Standard claims include:

• sub (subject) — the user identifier
• iat (issued at) — when the token was created
• exp (expiration) — when the token expires
• iss (issuer) — who created the token
• aud (audience) — who the token is intended for
• nbf (not before) — earliest time the token is valid

Applications add custom claims for roles, permissions, tenant IDs, and other authorization data. The payload is encoded, not encrypted, so anyone with the token can read its contents. Never put sensitive data like passwords or API keys in JWT claims.

The Signature

The signature ensures the token has not been tampered with. For HS256, the server creates the signature using a shared secret. For RS256, it uses a private key, and anyone with the public key can verify it. The signature covers both the header and payload, so changing any claim invalidates the token.

Common JWT Debugging Scenarios

Token Expired

The most frequent JWT issue is expiration. The exp claim is a Unix timestamp, and if the current time exceeds it, the token is invalid. Decode the token to check the exp value and compare it to the current time:

// Payload with expiration
{
  "sub": "user123",
  "exp": 1740000000,  // Check: is this in the past?
  "iat": 1739996400
}

// JavaScript check
const payload = JSON.parse(atob(token.split('.')[1]));
const isExpired = payload.exp * 1000 < Date.now();

Clock skew between servers can cause tokens to appear expired prematurely. Most JWT libraries accept a small leeway (typically 30–60 seconds) to account for this.

Wrong Audience or Issuer

In microservice architectures, tokens issued for one service should not be accepted by another. If your API rejects a valid-looking token, check the iss and aud claims to make sure they match what your service expects.

Algorithm Confusion Attacks

One of the most dangerous JWT vulnerabilities is the algorithm confusion attack. If a server is configured to accept RS256 tokens but does not validate the algorithm claim, an attacker can change the header to HS256 and sign the token using the public key as the HMAC secret. Always validate the alg header against an allowlist on the server side.

JWT Security Best Practices

JWTs are a powerful authentication mechanism, but they come with security considerations that every developer should understand:

• Always verify the signature before trusting any claims
• Validate exp, iss, and aud claims on every request
• Use asymmetric algorithms (RS256, ES256) for distributed systems where multiple services verify tokens
• Keep token lifetimes short (15 minutes for access tokens) and use refresh tokens for longer sessions
• Never store JWTs in localStorage for sensitive applications — use httpOnly cookies instead
• Implement token revocation through short expiry times or a server-side blocklist

For more on web security practices, see our Linux file security guide and the Base64 encoding guide which covers the encoding format JWTs use internally.

Decoding JWTs in Code

You can decode the header and payload without any library since they are just Base64URL-encoded JSON. But for signature verification, use a trusted library:

// Decode without verification (for inspection only)
function decodeJWT(token) {
  const [header, payload] = token.split('.').slice(0, 2)
    .map(part => JSON.parse(atob(part.replace(/-/g, '+').replace(/_/g, '/'))));
  return { header, payload };
}

// Verify with a library (Node.js jsonwebtoken)
const jwt = require('jsonwebtoken');
try {
  const decoded = jwt.verify(token, publicKey, {
    algorithms: ['RS256'],
    issuer: 'https://auth.example.com',
    audience: 'my-api'
  });
} catch (err) {
  console.error('Token invalid:', err.message);
}

Note the algorithms allowlist in the verify call. This prevents algorithm confusion attacks by explicitly declaring which algorithms your server accepts.

Decode and Inspect Tokens Instantly

The AI JWT Decoder parses any JWT instantly, showing you the decoded header, payload with formatted JSON, expiration status, and algorithm details. It highlights potential security issues like missing expiration claims or weak algorithms. Combine it with our JSON formatter for working with complex payload structures.

The AI JWT Decoder runs entirely in your browser, so your tokens never leave your machine. Paste a token from your API logs, browser dev tools, or authentication flow and instantly see what is inside, whether it has expired, and if there are any security red flags to address.