JSON Web Tokens (JWT, pronounced "jot") have become the standard for transmitting authentication and authorization data between systems. If you've ever logged into a web application and stayed authenticated across page refreshes, chances are JWT was involved.

What Is a JWT?

A JWT is a compact, URL-safe token that contains claims — pieces of information about an entity (typically a user) and additional metadata. JWTs are self-contained: the token itself carries all the data needed to verify its authenticity, without requiring a database lookup.

A typical JWT looks like this:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

That's three parts separated by dots: header, payload, and signature.

JWT Structure

Header

The header specifies the signing algorithm:

{
  "alg": "HS256",
  "typ": "JWT"
}

Common algorithms include HS256 (HMAC using SHA-256), RS256 (RSA using SHA-256), and ES256 (ECDSA using P-256 and SHA-256).

Payload

The payload contains claims. There are three types:

Registered claims — predefined: iss (issuer), exp (expiration), sub (subject), aud (audience)
Public claims — custom names defined by users
Private claims — custom names agreed upon by sender and receiver

Example payload:

{
  "userId": "1234567890",
  "name": "Alice",
  "role": "admin",
  "iat": 1700000000,
  "exp": 1700003600
}

Signature

The signature verifies the token hasn't been tampered with:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

The signature uses the header's algorithm with a secret key known only to the server. If anyone modifies the payload, the signature won't match, and the token is rejected.

How JWT Authentication Works

User logs in with credentials (email/password, OAuth, etc.)
Server validates credentials and creates a JWT with user claims
Server sends the JWT to the client
Client stores the JWT (localStorage, cookie, or memory)
Client sends the JWT in the Authorization header with each request: Authorization: Bearer <token>
Server verifies the signature and extracts claims
Server grants or denies access based on claims

Common Use Cases

API authentication — Stateless auth for REST and GraphQL APIs
Single sign-on (SSO) — Share authentication across multiple services
Microservices — Pass user context between services without shared sessions
Real-time communication — Authenticate WebSocket connections
Mobile apps — Tokens work across platforms without cookies

Security Considerations

Never store secrets in the payload

The payload is only encoded, not encrypted. Anyone can decode it. Never put passwords, API keys, or other secrets in a JWT payload.

Use short expiration times

Set exp to a reasonable value (15 minutes to 1 hour for access tokens). Use refresh tokens for longer sessions.

Validate all claims

Always check iss, aud, exp, and nbf (not before) claims on the server. Never trust a token without verification.

Use HTTPS

JWTs in transit must use HTTPS. Without TLS, tokens can be intercepted and replayed.

How to Decode a JWT

You can inspect any JWT without special tools — just Base64-decode the header and payload:

echo "eyJ1c2VySWQiOiIxMjM0NTY3ODkwIn0" | base64 -d

For a richer experience, use our JWT Decoder. It automatically detects the algorithm, shows whether the token is expired, and displays all claims in a readable format.

JWT vs Sessions

| Feature | JWT | Sessions | |---------|-----|----------| | Storage | Client-side | Server-side | | Scalability | Horizontal (stateless) | Requires shared store | | Revocation | Difficult (need blacklist) | Easy (delete session) | | Performance | No DB lookup per request | DB lookup per request | | Size | Grows with claims | Fixed (session ID) |

JWTs are ideal for stateless APIs and microservices. Sessions are better when you need immediate revocation (like banking apps).

Try It Now

Paste any JWT token into our JWT Decoder to instantly see the decoded header, payload, and signature — with expiration detection and claim analysis.