What Is a JWT Token and How Does It Work? Complete Guide for 2026

The Problem JWT Was Created to Solve

When you log into a website, the server needs to remember who you are for subsequent requests. HTTP is stateless by design, so each request starts fresh with no memory of previous ones.

The traditional approach uses server-side sessions. The server stores your session in memory or a database, sends you a session ID in a cookie and looks it up on every request. This works but requires shared session storage across all servers in a cluster and does not work well for APIs accessed by mobile apps or third-party services.

JWT takes a different approach. Instead of storing session data on the server, the server encodes all relevant information into a signed token and sends it to the client. The client sends this token with every request. The server verifies the cryptographic signature and extracts the data without any database lookup.

What a JWT Actually Contains

A JWT looks like three Base64URL-encoded strings joined by dots: 'header.payload.signature'.

The header contains the token type (JWT) and the signing algorithm (typically HS256 or RS256).

The payload contains claims, which are statements about the user and the token itself. Standard claims include 'sub' (subject, usually the user ID), 'exp' (expiration Unix timestamp), 'iat' (issued-at timestamp) and 'iss' (issuer). You can add custom claims like roles, permissions or any data your application needs.

The signature combines the encoded header and payload with a secret key (for HS256) or a private key (for RS256) using a cryptographic hash function. Any tampering with the payload changes the signature, and the server rejects the token.

What the Decoded Payload Looks Like

After decoding the Base64URL payload, you get a plain JSON object:

{
  "sub": "user_12345",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1704067200,
  "exp": 1704153600
}

The 'exp' field is a Unix timestamp. When this timestamp is in the past, the server rejects the token as expired. This is why JWT authentication errors often say "token expired". Short expiration times are a security feature, not a bug.

Security Facts Every Developer Should Know

JWTs are not secret by default. The header and payload are only encoded, not encrypted. Anyone who gets your token can decode and read everything in the payload. Never put passwords, credit card numbers or genuinely sensitive data in a JWT payload.

The signature protects integrity, not confidentiality. Nobody can modify the token without the server detecting it, but anyone can read it.

Keep expiration times short. Because JWTs cannot be revoked without extra infrastructure, short lifetimes limit damage if a token is stolen. Access tokens typically expire in fifteen minutes to one hour. Refresh tokens last longer and are used to obtain new access tokens.

Watch out for the 'alg: none' vulnerability in older libraries. Some early JWT implementations accepted tokens with the algorithm set to 'none', requiring no signature verification. Always explicitly allowlist which algorithms your server accepts.

How to Inspect a JWT

When debugging API authentication, our JWT Decoder tool decodes any token instantly. Paste the JWT and see the complete header, payload and signature breakdown with human-readable timestamps for the 'exp' and 'iat' fields.

Useful for confirming which user ID or role is encoded, checking whether a token is expired or verifying the token format when troubleshooting authentication issues.