Ultimate Guide · 2026
JWT vs Opaque Session Tokens: When Your API Should Use Each
Two token systems both prove “you are logged in,” but they store the proof in completely different places. A JWT hides itself in the token — stateless and readable by anyone holding it. An opaque session token references data your server keeps — stateful, revocable at an instant. Choosing wrong means login pages that are needlessly slow, tokens that cannot be revoked, or user data that leaks in every bearer string. Here is how to decide.
Written by Benjamin Rotshtein
Updated
The core difference: stateless vs stateful
A JWT is a self-contained bundle: header, payload, and a signature you verify with a key. The verifying server needs no shared session record — just the key. An opaque token is a random string that acts as a database key. To authenticate, the server must look the token up in a session store before it knows anything.
That one sentence explains most of the trade-offs that follow: where the JWT gains speed and no lookup, it loses instant revocation and keeps its whole payload readable by anyone holding it.
Side by side
| Criterion | JWT | Opaque token |
|---|---|---|
| State | Stateless — the token itself carries the data | Stateful — a server store maps token → session |
| Revocation | Awkward — you need a denylist or short expiry | Trivial — delete the session record to revoke instantly |
| Readable payload | Anyone can Base64-decode header & payload | Random string, unreadable by design |
| DB hits per request | None (if signature verified with a key) | One on every request to look up the session |
| Expiry handling | Baked into exp claim | Encoded in the stored session |
| Best for | Microservices, read-heavy, no central store | Server-rendered apps, sensitive data, revocable logins |
Revocation is the deal-breaker for most apps
Opaque tokens win on revocation by construction. “Log out everywhere” is just a single SQL delete. A stolen JWT, by contrast, is valid until it expires — nobody is going to refresh a leaked stateless credential, so any leaked JWT keeps working. That is why bank sites, admin panels and anything handling user-billing typically reach for opaque tokens.
The JWT payload is readable — decide what belongs in it
This is the point you will get wrong most often. A JWT is signed, not encrypted. Paste one into a JWT decoder and the payload text is right there. With an opaque token there is nothing to decode, because the real session lives on your server.
A quick decision rule
- Use JWT when several services verify the same token without a shared store, when you want to skip a database round-trip, or when instant revocation is not a hard requirement.
- Use opaque when you must revoke instantly, depends on the server, or prefer that user data never be readable in a bearer token. Many well-trodden, high-res apps fall here.
- Hybrid is common and fine: an opaque, revocable session token that carries a short-lived JWT for internal claims.
If you already ship JWTs and are not sure what is in your payload, decode one and force yourself to a hard look — it is exactly the thing a token inspector is built for.
Frequently asked questions
Is a JWT the same as a session?
No. A session is state kept on the server, referenced by an opaque (random) token. A JWT carries the user data itself and can be verified without any server-side session. JWTs are commonly used as a session carrier, but they are not sessions — they are self-contained, stateless credentials.
Can a leaked JWT be revoked?
Not easily. Because the server holds no record per token, there is nothing to delete. To revoke a JWT you need a blacklist, a short expiry plus refresh rotation, or a token version stored server-side. Opaque tokens revoke instantly by deleting the session record.
Why would anyone use JWT if opaque tokens are simpler?
JWTs remove the session-store lookup on every request, which matters at scale and in microservices where any service can verify a bearer token with a shared key. They also let you assert roles or features without a database round trip. The cost is a harder revocation problem and clear payload data.
Is the JWT payload secure?
No — the header and payload are only Base64-encoded, not encrypted. Anyone who sees the token can read every claim. Opaque tokens do not expose data by design, because the actual session lives server-side.
When should I definitely avoid JWT?
When instant revocation matters (active logout for a single user, security breach), when you don't want user data readable by any bearer, or when your sessions are short-lived and a database lookup is cheap. These all point to opaque tokens over JWTs.
See exactly what your token carries — 100% in your browser
Decode a JWT, inspect Base64 and URLs, and generate hashes without the token ever leaving your machine. Difference between a string that verifies and a session that revokes.