No. A JWT is base64url-encoded, not encrypted. The payload is readable by anyone who has the token — just paste it into a JWT decoder to see the contents. If you need to protect the payload from being read (not just tampered with), use a JWE (JSON Web Encryption) instead.

Where should I store a JWT on the client?

The safest option is an HttpOnly cookie — it cannot be accessed by JavaScript, so it is immune to XSS attacks. The browser sends it automatically on every request to the same domain. Storing in localStorage is common and convenient, but makes the token accessible to any JavaScript running on the page, including malicious scripts.

Can a JWT be invalidated before it expires?

Not natively — that is a known limitation of the stateless JWT model. Once issued, a token is valid until its exp timestamp, regardless of what happens server-side. Common workarounds: keep expiration times short (15 minutes), use a refresh token rotation pattern, or maintain a server-side token blocklist for critical actions like logout.

What is the difference between a JWT and a session token?

A session token is an opaque random string that maps to user state stored on the server (database or cache). Every request requires a server-side lookup to validate it. A JWT is self-contained: all the information needed to validate and identify the user is inside the token itself. The server only needs the secret key — no database call.

What is a JWT Token?

What is a JWT?

A JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transmit information between two parties as a JSON object. The information is digitally signed, which means it can be verified and trusted.

JWTs are most commonly used for authentication: once a user logs in, the server issues a JWT. The client includes that token in subsequent requests, and the server validates it without needing to query a database on every call.

The three parts of a JWT

A JWT is a string of three base64url-encoded parts separated by dots:

.payload.signature

example JWTeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyLCJleHAiOjE3MTYyNDI2MjJ9.r8d5mFpCpFTKJzn0xqQ4p9klO8KxD2yKpBiAqJf1234

Header

The header declares the token type (JWT) and the signing algorithm (alg). After base64url decoding:

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

Payload

The payload contains claims — statements about the user or additional data. Standard claims include:

sub — subject (usually the user ID)
iat — issued at (Unix timestamp)
exp — expiration time (Unix timestamp)
iss — issuer (who created the token)
aud — audience (who the token is intended for)

decoded payload{"sub": "1234567890", "name": "Jane Doe", "iat": 1716239022, "exp": 1716242622}

Important: The payload is base64url-encoded, not encrypted. Anyone who has the token can decode and read the payload. Never store sensitive data (passwords, secrets) in a JWT payload.

Signature

The signature is computed by taking the encoded header and payload, joining them with a dot, and signing with the algorithm and a secret key:

signature (HS256)HMACSHA256(base64url(header) + "." + base64url(payload), secretKey)

The signature guarantees that the token hasn't been tampered with. If anyone modifies the payload, the signature no longer matches and the server rejects the token.

How JWT authentication works

Login — the user submits credentials. The server verifies them and creates a signed JWT.
Storage — the client receives the token and stores it (cookie or memory).
Request — on each API call, the client sends the token in the Authorization header:
Authorization: Bearer <token>
Verification — the server validates the signature and checks exp. If valid, the request is authorized. No database lookup needed.

Signing algorithms

AlgorithmTypeUse case

HS256 / HS384 / HS512Symmetric (HMAC)Single service — one shared secret for both signing and verification

RS256 / RS384 / RS512Asymmetric (RSA)Distributed systems — private key signs, public key verifies (services don't need the secret)

ES256 / ES384 / ES512Asymmetric (ECDSA)Same as RSA but smaller tokens and faster operations

When in doubt, use HS256 for simple internal services and RS256 when multiple services need to verify tokens without sharing a secret.

Security best practices

Always verify the signature — never decode a JWT and trust the payload without checking the signature first.
Check the exp claim — reject expired tokens even if the signature is valid.
Use short expiration times — 15–60 minutes for access tokens, longer for refresh tokens.
Store in HttpOnly cookies — immune to XSS attacks, unlike localStorage.
Use HTTPS — tokens in transit must be encrypted.
Validate the alg header — some libraries historically accepted "alg": "none", bypassing signature verification entirely. Always enforce the expected algorithm server-side.