What is JWT — How Token Authentication Works

If you've built or used a modern web application, you've likely encountered JWT (JSON Web Tokens). They're the most popular method for handling authentication in single-page apps, mobile apps, and microservice architectures. This guide explains how they work from the ground up.

The Authentication Problem

HTTP is stateless — every request is independent. The server doesn't inherently know if two requests come from the same logged-in user. Traditional solutions used server-side sessions (storing user state on the server), but this doesn't scale well across multiple servers or microservices.

JWT solves this by putting the user's identity inside the token itself. The server doesn't need to store anything — it just verifies the token's signature on each request.

How JWT Authentication Works

1. Login: User sends username + password to the server
2. Token creation: Server verifies credentials, creates a JWT containing user info, signs it with a secret key
3. Token sent: Server returns the JWT to the client
4. Storage: Client stores the token (usually in localStorage or memory)
5. Authenticated requests: Client sends the token in the Authorization: Bearer <token> header with every request
6. Verification: Server validates the signature and reads user info from the token — no database lookup needed

JWT Structure: Three Parts

A JWT looks like this: xxxxx.yyyyy.zzzzz — three Base64-encoded parts separated by dots.

Part 1: Header

Specifies the signing algorithm (HS256, RS256, etc.) and token type.

Part 2: Payload (Claims)

Contains the actual data — user ID, name, roles, issue time, and expiration. These are called "claims."

Part 3: Signature

Created by hashing the header + payload with a secret key. This prevents tampering — if anyone modifies the payload, the signature won't match and the server rejects the token.

Common JWT Claims

Security Best Practices

• Set short expiration — 15 minutes for access tokens, use refresh tokens for longer sessions
• Never store sensitive data in the payload — it's encoded, not encrypted (anyone can decode it)
• Use HTTPS only — tokens sent over HTTP can be intercepted
• Don't store in localStorage for high-security apps — vulnerable to XSS attacks. Use httpOnly cookies instead
• Validate all claims — check expiration, issuer, and audience on every request
• Use RS256 for public APIs — allows verification without sharing the secret key

Decode a JWT

Want to inspect what's inside a JWT? Use our free JWT Decoder — paste any token and instantly see the header, payload, expiration status, and all claims. It runs entirely in your browser — your tokens are never sent to a server.