Calculators Converters Generators Developer Tools Finance Tools Writing Tools SEO Tools Image Tools Network Tools Productivity Tools Social Media Tools
Blog About Contact
USD ($)
Dev ToolsMarch 18, 2026• 7 min read

JWT Tokens Explained: What They Are and How They Work

JWT Tokens Explained: What They Are and How They Work

JSON Web Tokens (JWTs) are everywhere in modern web development. They power authentication in millions of applications, from single-page apps to mobile backends. Here's everything you need to know.

What Is a JWT?

A JWT is a compact, URL-safe token that represents claims between two parties. It's commonly used for authentication — after a user logs in, the server issues a JWT that the client sends with subsequent requests to prove identity.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The Three Parts of a JWT

A JWT consists of three Base64URL-encoded parts separated by dots:

1. Header

Contains the token type and signing algorithm:

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

2. Payload

Contains the claims (data). Common standard claims include:

• sub — Subject (usually user ID)

• iat — Issued at (timestamp)

• exp — Expiration time

• iss — Issuer

• aud — Audience

3. Signature

Created by signing the header and payload with a secret key. This ensures the token hasn't been tampered with.

How JWT Authentication Works

1. User sends credentials (username/password) to the server

2. Server verifies credentials and generates a JWT

3. Server sends the JWT back to the client

4. Client stores the JWT (usually in memory or httpOnly cookies)

5. Client sends the JWT with every subsequent request in the Authorization header

6. Server verifies the JWT signature and extracts user data from the payload

JWT Security Best Practices

1. Always verify the signature — Never trust a JWT without validation

2. Set short expiration times — 15-60 minutes for access tokens

3. Use refresh tokens — Separate long-lived refresh tokens from short-lived access tokens

4. Store tokens securely — httpOnly cookies are safer than localStorage

5. Never put sensitive data in the payload — JWTs are encoded, NOT encrypted

6. Use strong signing keys — At least 256 bits for HMAC algorithms

7. Validate all claims — Check issuer, audience, and expiration

Common JWT Mistakes

1. Storing JWTs in localStorage — Vulnerable to XSS attacks

2. Not validating expiration — Expired tokens should always be rejected

3. Using weak secrets — "secret123" is not a secret

4. Putting passwords in the payload — Anyone can decode the payload

5. Not using HTTPS — JWTs sent over HTTP can be intercepted

Ready to try it yourself?

Use our free JWT Decoder to apply what you have learned.

Open JWT Decoder →

Frequently Asked Questions

JWT is secure when implemented correctly. The signature prevents tampering, but the payload is only Base64-encoded — not encrypted. Never store sensitive data like passwords in a JWT. Always use HTTPS and validate signatures server-side.
Session tokens are stored on the server (in a database or memory) and referenced by an ID. JWTs are self-contained — the server does not need to store them. JWTs are stateless and scale better, but cannot be easily revoked.
Access tokens should be short-lived: 15 minutes to 1 hour. Refresh tokens can be longer: days to weeks. Shorter durations limit the damage if a token is compromised.
Yes — the header and payload are simply Base64URL-encoded, not encrypted. Anyone can decode them. The secret key is only needed to verify the signature (prove the token was not tampered with). Use our JWT Decoder to inspect any token.
It depends. JWTs work well for stateless APIs and microservices where server-side state is impractical. For traditional web apps, server-side sessions with cookies may be simpler and more secure due to easier revocation.