JWT Interview Questions and Answers (2026)

When a hiring manager asks about JWTs, they’re looking for two things: a clear mental model of how the token works, and the ability to reason about security and architecture decisions. Below are the most common questions you’ll hear, a short spoken answer you can deliver in 45‑90 seconds, and the next question the interviewer often asks.

1. What is a JWT and what are its three parts?

A JSON Web Token is a compact, URL‑safe string that carries a set of claims. It has three base64url‑encoded sections separated by dots: Header, Payload, and Signature. The header tells you which signing algorithm was used, the payload holds the claims (like sub, exp, iat), and the signature protects the token from tampering.

Typical follow‑up: "How does the signature protect the token?"

2. How does a JWT differ from a traditional session cookie?

A session cookie stores a server‑generated identifier; the server looks up the session state on each request. A JWT is self‑contained: it carries the needed claims, so the server can verify the signature and trust the data without a lookup. This reduces database round‑trips and scales well for stateless services, but it also means you lose immediate revocation unless you build extra checks.

Typical follow‑up: "When would you still prefer sessions?"

3. What are the security considerations when storing a JWT on the client?

Never store a JWT in plain‑text localStorage if you’re vulnerable to XSS; the token can be stolen. Prefer an HttpOnly, Secure cookie, or use the browser’s Authorization header with a short‑lived token stored in memory. If you must store it in localStorage, mitigate XSS aggressively and rotate the token often.

Typical follow‑up: "What about CSRF?"

4. How do you handle token expiration and refresh?

Include an exp claim that defines a short lifetime (often 5‑15 minutes). When the token expires, the client uses a longer‑lived refresh token to request a new JWT from an endpoint. The refresh token should be stored more securely (e.g., HttpOnly cookie) because it can be used to obtain new access tokens.

Typical follow‑up: "Can you revoke a refresh token?"

5. Explain token revocation strategies.

Since a JWT is stateless, revocation isn’t built‑in. Common approaches include:

• Blacklist: Store revoked token IDs in a fast store (Redis) and check on each request.
• Short lifetimes: Reduce the window of exposure by making access tokens brief.
• Rotation: Issue a new refresh token on each use and invalidate the previous one.
• Versioning: Include a token_version claim that you bump when a user logs out or changes credentials.

Typical follow‑up: "What are the performance impacts of a blacklist?"

6. What algorithms are recommended for signing JWTs?

Use an asymmetric algorithm like RS256 or ES256 for public‑key verification, especially in microservice environments where many services need to validate tokens without sharing a secret. HMAC‑SHA256 (HS256) is fine for single‑service scenarios, but you must protect the secret carefully.

Typical follow‑up: "How do you rotate keys without breaking clients?"

7. How would you embed custom claims, and what should you avoid?

Add domain‑specific claims (e.g., role, org_id) to the payload. Keep them small and avoid sensitive data like passwords or personally identifiable information, because the payload is only base64‑encoded, not encrypted. If you need confidentiality, encrypt the JWT or use a separate encrypted payload.

Typical follow‑up: "Can you encrypt a JWT?"

8. Describe a real‑world scenario where you chose JWTs.

Sample answer: "In a recent project I built a set of microservices that needed to authenticate API calls from a mobile app. I chose JWTs because the services were stateless and deployed across multiple regions. The token contained the user ID, role, and a short expiration. We used RS256 so each service could verify the token with a shared public key, eliminating a central auth store. To handle revocation, we paired short‑lived access tokens with a refresh token stored in an HttpOnly cookie, and we rotated the refresh token on each use. This reduced latency and kept the architecture simple while still meeting our security requirements."

Typical follow‑up: "How did you monitor token misuse?"

9. What are the pitfalls of using JWTs for authorization?

Because JWTs are self‑contained, they can become stale if a user's permissions change. If you rely solely on the token’s claims, you might grant access longer than intended. Mitigate this by keeping token lifetimes short, using a version claim that you bump on permission changes, or by checking permissions against a central store for high‑risk actions.

Typical follow‑up: "How would you design a fallback check?"

10. How do you test JWT handling in your codebase?

Write unit tests that verify:

• Correct header and payload encoding.
• Signature verification for both valid and tampered tokens.
• Expiration handling.
• Revocation logic (e.g., blacklist lookup).

Integration tests should exercise the full auth flow: login → receive JWT → call a protected endpoint → refresh token.

Typical follow‑up: "Do you mock the key store in tests?"

---

How to practice this

1. Record yourself answering each question aloud; aim for 45‑90 seconds per answer. Replay the recording to trim filler words.
2. Use Call Assistant to simulate an interview: let it detect the question, cue your answer, and suggest the next logical follow‑up so you stay on topic.
3. Iterate with a peer: swap answers and give feedback on clarity, technical depth, and relevance to your resume.

---

FAQ

• Q: Should I always use JWTs for authentication? A: Not necessarily. JWTs shine in stateless, distributed systems, but for simple monolithic apps a session cookie may be easier to manage and revoke.
• Q: Is storing a JWT in a cookie safe from XSS? A: Yes, if the cookie is HttpOnly and Secure, it cannot be accessed via JavaScript, reducing XSS risk. However, you still need CSRF protection.
• Q: How often should I rotate signing keys? A: Rotate keys on a schedule that balances operational overhead with risk—monthly or quarterly is common in larger teams, but shorter intervals are fine if your deployment pipeline supports it.
• Q: Can I encrypt a JWT instead of signing it? A: You can use JWE (JSON Web Encryption) to encrypt the payload, but this adds complexity. Often signing plus transport‑level TLS is sufficient.