AI JWT Decoder — Decode and Verify JWT Tokens Instantly

Published February 23, 2026 · 9 min read · Security

It is 11 PM and your API is returning 401 errors. Users are getting logged out randomly. You grab a token from the request headers and stare at a wall of base64 text: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi.... You need to know what is inside that token right now — is it expired? Does it have the right claims? Is the audience correct?

A JWT decoder answers all of these questions in seconds. Paste the token, see the decoded header and payload, check the expiration time, and verify the signature. No libraries to install, no code to write.

What Is a JSON Web Token

A JWT (pronounced "jot") is a compact, URL-safe token format defined in RFC 7519. It consists of three parts separated by dots:

header.payload.signature

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature

Each part is base64url-encoded JSON. The header declares the algorithm and token type. The payload contains the claims (the actual data). The signature ensures the token has not been tampered with.

The Header

The header typically contains two fields:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "my-key-id"
}

alg — the signing algorithm (HS256, RS256, ES256, EdDSA)
typ — always "JWT"
kid — key ID, used to look up the correct public key when multiple keys are in rotation

The Payload (Claims)

The payload carries the claims. Some are registered (standardized), others are custom:

{
  "sub": "user-12345",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "exp": 1771891200,
  "iat": 1771804800,
  "roles": ["admin", "editor"]
}

sub (subject) — who the token represents
iss (issuer) — who created the token
aud (audience) — who should accept the token
exp (expiration) — Unix timestamp when the token expires
iat (issued at) — when the token was created
nbf (not before) — token is not valid before this time

A JWT token decoder converts those Unix timestamps into human-readable dates and highlights expired tokens immediately. When you are debugging at 11 PM, that saves real time.

Symmetric vs Asymmetric Signing

HMAC (HS256, HS384, HS512)

Symmetric signing uses a shared secret. The same key signs and verifies the token. This is simple but means every service that needs to verify tokens must have the secret. If any service is compromised, all tokens can be forged.

HMAC-SHA256(
  base64urlEncode(header) + "." + base64urlEncode(payload),
  secret
)

Use HMAC when a single service both creates and verifies tokens, like a monolithic application with session tokens.

RSA and ECDSA (RS256, ES256)

Asymmetric signing uses a private key to sign and a public key to verify. The auth server keeps the private key; all other services only need the public key. Even if a service is compromised, attackers cannot forge new tokens.

This is the standard for microservices architectures and any system where multiple services need to verify tokens independently. Most OAuth 2.0 and OpenID Connect providers use RS256 or ES256.

Security note: Never put sensitive data in JWT payloads. The payload is only base64-encoded, not encrypted. Anyone with the token can decode and read the claims. Use JWE (JSON Web Encryption) if you need encrypted payloads. A hash generator can help you understand the cryptographic primitives behind JWT signatures.

Common JWT Debugging Scenarios

Token Expired

The most common JWT issue. The exp claim is a Unix timestamp. If the current time is past this value, the token is rejected. Clock skew between servers can cause tokens to appear expired on one server but valid on another. Most libraries allow a small leeway (typically 30–60 seconds).

Wrong Audience

The aud claim must match what the verifying service expects. If your auth server issues tokens with "aud": "https://api.example.com" but your service checks for "aud": "api.example.com" (without the protocol), verification fails silently.

Algorithm Confusion Attack

A classic vulnerability: the attacker changes the header algorithm from RS256 to HS256 and signs the token with the public key (which is, well, public). If the server naively uses the algorithm from the header, it verifies the token using the public key as an HMAC secret — and the forged token passes. Always validate the algorithm server-side; never trust the token header alone.

Missing or Wrong Claims

Your API expects a roles claim but the token only has scope. Or the sub claim uses a different format than your database expects. A JWT debugger lets you see exactly what claims are present before you start adding console.log statements everywhere.

JWT Best Practices for Production

Keep tokens short-lived (15 minutes for access tokens, hours or days for refresh tokens)
Use asymmetric algorithms (RS256 or ES256) for distributed systems
Validate iss, aud, and exp on every request
Never store JWTs in localStorage (vulnerable to XSS); use httpOnly cookies
Implement token rotation and revocation for refresh tokens
Use kid (key ID) to support key rotation without downtime

If you are building authentication systems, you will also want to secure your endpoints with proper password hashing and SSL certificates. JWT is one layer in a defense-in-depth strategy.

Decoding JWTs from the Command Line

Sometimes you need to decode a token in a script or CI pipeline. Here is how to do it without any dependencies:

# Decode JWT payload using bash
echo "eyJzdWIiOiIxMjM0NTY3ODkwIn0" | \
  tr '_-' '/+' | \
  base64 -d 2>/dev/null | \
  python3 -m json.tool

# Using jq (if installed)
jwt="eyJhbGci..."
echo "$jwt" | cut -d. -f2 | base64 -d 2>/dev/null | jq .

This works for quick checks, but a visual JWT decoder is faster when you need to inspect multiple tokens or verify signatures. It also converts timestamps, highlights expired tokens, and formats the JSON for readability.

For related encoding and decoding tasks, check out the Base64 encoder/decoder guide which covers the encoding format that JWTs are built on.

Decode any JWT token instantly — see headers, claims, and expiration

Paste your token to inspect the payload, verify the signature, and debug authentication issues in seconds.

Try AI JWT Decoder →

When Not to Use JWTs

JWTs are not a universal solution. They are stateless, which means you cannot revoke a specific token without maintaining a blocklist (which defeats the stateless benefit). For applications that need instant logout or session management, server-side sessions with a timestamp check may be simpler and more secure.

JWTs also grow in size as you add claims. A token with many roles, permissions, and metadata can exceed 4KB, which is the cookie size limit in most browsers. If your tokens are getting large, consider using opaque tokens with a token introspection endpoint instead.

The right choice depends on your architecture. JWTs excel in distributed systems where services need to verify identity without calling a central auth server. For monolithic applications, traditional sessions are often simpler and more flexible.