Where should I store JWTs — localStorage or cookies?

HttpOnly cookies are more secure — inaccessible to JavaScript. localStorage is vulnerable to XSS. Use HttpOnly Secure SameSite=Strict cookies unless cross-domain requests require JavaScript access.

Standard JWTs are signed (JWS) but not encrypted — the payload is base64-encoded and readable by anyone. Never put sensitive data in a JWT payload. Use JWE for encryption, though this is uncommon.

JWT vs Session Tokens

Q: Where should I store JWTs on the client — localStorage or cookies?

Cookies with HttpOnly; Secure; SameSite=Strict are more secure: they're inaccessible to JavaScript, preventing XSS-based token theft. localStorage is accessible to any JavaScript running on the page — a single XSS vulnerability exposes every token. Use HttpOnly cookies for JWTs unless your architecture requires JavaScript to read the token (cross-domain requests from a SPA). If you must use localStorage, ensure strict CSP headers and input sanitization to reduce XSS risk.

Compare JWTs and server-side session tokens for authentication. Stateless vs stateful, revocation trade-offs, and when each approach fits.

Why This Comparison Matters

Choosing between JWTs and session tokens is an architectural decision with real security implications. JWTs are stateless — the server doesn't store anything, making them natural for microservices and mobile apps. Session tokens require a session store but give you instant revocation, which JWTs cannot provide without extra infrastructure.

Stateless vs stateful: JWTs carry all claims inside the token — no server storage needed; session tokens are opaque IDs backed by a server-side store (Redis, DB)
Revocation: Session tokens are revoked instantly by deleting the session; JWTs remain valid until expiry — revocation requires a token blacklist (extra infra)
Payload size: JWTs grow with each claim — large payloads add overhead to every request; session IDs are typically 32–128 bytes
Microservices: JWTs work without shared session storage — services verify the token independently; sessions require all services to access the central store
When to use JWTs: Microservices, mobile apps, cross-domain authentication, short-lived access tokens
When to use sessions: Traditional web apps, admin dashboards, anywhere instant logout/revocation is required

Decode a JWT →

Quick Comparison Table

Storage: JWT: none server-side; Session: server-side store required
Revocation: JWT: hard without a blacklist; Session: instant
Payload size: JWT: grows with claims; Session ID: ~32–128 bytes
Scalability: JWT: horizontal scaling is easy; Session: requires sticky sessions or shared store
Cross-domain: JWT: works natively; Session: requires CORS + cookie config
Expiry control: JWT: embedded exp claim; Session: server sets TTL
Security risk: JWT: stolen token valid until expiry; Session: stolen ID invalidated on logout

Choose the Right Variant

This page: JWT vs session tokens — architecture, security, and use case comparison
JWT Decoder: Decode and inspect JWT header, payload, and claims

Privacy and Data Handling

JWT decoding runs entirely in your browser. Tokens are never sent to any server — safe to use with tokens containing sensitive claims.

Frequently Asked Questions

Can I revoke a JWT before it expires?

Not without additional infrastructure. A JWT is cryptographically self-contained — any service with the public key can verify it, regardless of whether you've "invalidated" it. To revoke JWTs early, you need either: (1) a token blacklist stored in Redis that every service checks on each request, or (2) very short-lived access tokens (5–15 minutes) paired with refresh tokens that can be revoked. Short expiry is the most common practical approach. If instant revocation is a hard requirement, use session tokens instead.

Where should I store JWTs on the client — localStorage or cookies?

Cookies with HttpOnly; Secure; SameSite=Strict are more secure: they're inaccessible to JavaScript, preventing XSS-based token theft. localStorage is accessible to any JavaScript running on the page — a single XSS vulnerability exposes every token. Use HttpOnly cookies for JWTs unless your architecture requires JavaScript to read the token (cross-domain requests from a SPA). If you must use localStorage, ensure strict CSP headers and input sanitization to reduce XSS risk.

Are JWTs encrypted?

By default, no. A standard JWT (JWS — JSON Web Signature) is signed but not encrypted: the header and payload are base64-encoded and readable by anyone with the token. Only the signature verifies authenticity and prevents tampering. To inspect a JWT's contents, paste it into the JWT decoder — you'll see the full payload. For encrypted JWTs, use JWE (JSON Web Encryption) — but this is much less common. Never put sensitive data (passwords, credit cards, SSNs) in a standard JWT payload.