Back to News & Insights
Web Development August 31, 2026 · 8 min read

Sessions vs JWTs: you are choosing how often you pay for state

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for...

Sessions vs JWTs: you are choosing how often you pay for state

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.

Every app you have ever built had to answer the same question on every single request.

Sessions, where the server remembers you. And JWTs, where the server hands you a signed note and promptly forgets you exist.

The internet has mostly decided that JWTs are the modern one and sessions are what your grandfather used in PHP.

That framing is wrong, and it leads people into a specific trap that I want to walk you through properly.

You log in. The server checks your password, and if it is happy, it writes a row somewhere.

That row holds your user id, an expiry, maybe your roles. It lives in Redis, or Postgres, or memory if you are feeling brave.

On every request after login, the server takes your session id, goes to the store, and asks "who is this again?"

This has a consequence people underrate: the server can change its mind about you instantly.

Delete the row and the very next request from that cookie is a stranger. Ban a user, force a logout, revoke a compromised session, all of it is a DELETE.

But instead of writing a row, the server builds a small JSON object, signs it, and hands the whole thing to you.

Here is the single most important thing about that payload, and the thing I see people get wrong in production code:

A JWT is signed, not encrypted. Anyone holding the token can read every claim inside it. jwt.io will do it for you in a browser.

No secrets, no internal flags you would rather users not see, no "isTrialAbuser": true.

With sessions, the truth lives on your server, and the client holds a pointer to it.

With JWTs, the truth lives in the client's pocket, and your server holds a way to check the handwriting.

Sessions need every server to reach the same store, which means a network hop on every request and one more thing in your architecture that must never go down.

Every server has the key, every server verifies locally, and adding a fourth server is a non-event.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation