What Is a JWT and How Does It Work?
Reviewed by Gurusankar M. · Updated Aug 24, 2026
⚡ Short Answer
A JWT (JSON Web Token) is a compact, self-contained token — header.payload.signature, each Base64url-encoded and joined by dots. The payload carries claims (user id, roles, expiry) that any service can read and verify locally via the signature, with no round trip to a central session store. It's signed, not encrypted, so it proves integrity (not tampered with) but never guarantees confidentiality.
☕Coffee Chat Question
Concept Made Simple
“What is a JWT and how does it work?”
🧠Mind Map Answer
Remember It Faster
A JWT is a movie ticket 🎬. The cinema doesn't keep a list of who bought tickets — your stub already proves you paid, and the watermark (signature) proves it's not forged. The server stays stateless.
Format: header.payload.signature — three Base64 parts joined by dots.
HS256 vs RS256 is the algorithm choice interviewers probe next. HS256 is symmetric — one shared secret both signs and verifies, so every service that needs to verify a token also needs that same secret, which means every service that has it could also forge tokens. RS256 is asymmetric — a private key signs (held only by the auth service), and a public key verifies (safely distributed to every other service). Microservice architectures default to RS256 for exactly this reason: services that only need to verify tokens never need access to anything that could mint new ones.
Expiry and revocation are the trade-off that actually bites in production. A JWT's statelessness is also its weakness: once issued, a service can't "unissue" it — there's no server-side session to delete. If a user's access needs to be revoked immediately (they're fired, their account is compromised), a short-lived access token (minutes) paired with a separate, server-tracked refresh token is the standard fix — the refresh token can be revoked in a database lookup, and the access token's short expiry bounds how long a compromised token stays valid even if revocation is delayed.
With RS256, key rotation happens through a JWKS endpoint, not a config file. The auth service publishes its current public key(s) at a well-known URL (/.well-known/jwks.json) as a JSON Web Key Set — each key tagged with a kid (key id). A verifying service fetches and caches that JWKS, and when it needs to verify a token, reads the kid from the token's header to pick the matching public key out of the set, rather than hardcoding one key. That's what makes rotation safe without downtime: the auth service publishes a new key into the JWKS (old key stays present too), starts signing new tokens with it, and only removes the old key from the JWKS once every token signed with it has naturally expired — verifiers never need a synchronized deploy.
A valid signature is necessary but not sufficient — the claims still have to be checked. A properly signed token from a different application, or one that's simply expired, still passes signature verification if nothing else is validated. The checklist interviewers expect: exp (has it expired), nbf (not-before — is it valid yet), iss (issuer — was this actually minted by your auth service, not some other service using the same key infrastructure), and aud (audience — was this token meant for this API, not a different one that happens to trust the same issuer). Skipping iss/aud checks is a real, recurring vulnerability class: a token legitimately issued for one service ends up accepted by another service it was never intended for, simply because both trust the same signing key.
⌨️Hands-on Keyboard
Learn by Doing
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMDEiLCJyb2xlIjoiYWRtaW4ifQ.S1g...
^header ^payload ^signature🔥What If?
Think Beyond the Expected
If the payload is just Base64, can anyone read it?
Yes — JWTs are signed, not encrypted. Never put secrets in the payload. The signature only guarantees integrity, not confidentiality.
😂Real World
After login your API returns a JWT; the frontend stores it and sends it in the Authorization header on every request. Each microservice verifies the signature locally — no shared session store, which is exactly why JWTs scale so well across services.
🎯Interviewer's Expectation
Keywords they're listening for:
⚠️Common Mistakes
- ✗Putting secrets (passwords, PII) in the payload, forgetting it's signed, not encrypted
- ✗Using one long-lived token instead of a short-lived access token + revocable refresh token
- ✗Storing JWTs in localStorage, exposing them to XSS, instead of an httpOnly cookie
- ✗Trusting the client-decoded payload without verifying the signature server-side
✅Best Practices
- ✓Keep access tokens short-lived; use a revocable refresh token for anything longer
- ✓Prefer RS256 (asymmetric) over HS256 when multiple services need to verify tokens
- ✓Store tokens in an httpOnly, Secure cookie rather than localStorage where practical
- ✓Always verify the signature server-side — never trust a client-decoded payload
🔁Follow-up Questions
- 1Why is a JWT signed instead of encrypted, and when would you need both?
- 2HS256 vs RS256 — why do microservices usually prefer RS256?
- 3How do you revoke a JWT before it expires?
- 4Where should the frontend store a JWT — localStorage, a cookie, or memory?
📚References
Continue Learning with AI
Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.
Plain-language foundations
I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner. Topic: Auth (REST APIs) Interview question: "What is a JWT and how does it work?" Please: 1. Explain the core idea in simple, plain language, using an everyday analogy. 2. Define any technical terms you use. 3. Walk through one small, concrete example. 4. Finish with a single sentence I can easily remember. Keep the tone friendly and assume I'm new to this topic.
Was this answer helpful?
⭐ Featured Products
Support our platform by exploring our recommended products.
As an Amazon affiliate, purchases through these links may earn us a small commission — at no extra cost to you. It helps keep Full Stack Interview Guru free.