JWT (JSON Web Token)
What is a JWT?
A JWT, short for JSON Web Token, is a compact and self-contained token format defined by RFC 7519. It lets two parties exchange a set of claims (who the user is, what they may do, when the token expires) in a form that can be verified because it is digitally signed. In practice, a server issues a JWT after a successful login, the client stores it, and every later request to the API carries it so the server knows who is calling without looking up a session.
The key idea is that the token carries its own information. Instead of keeping a session record in a database, the server only needs the secret or public key used to check the signature. That makes JWTs popular for stateless authentication in modern web applications, mobile apps and microservices.
How a JWT is structured
A JWT is three Base64URL-encoded parts separated by dots: header.payload.signature.
- Header: the token type and the signing algorithm, for example
{"alg":"HS256","typ":"JWT"}. - Payload: the claims. Registered claims include
sub(subject),iss(issuer),aud(audience) andexp(expiration time). You can add custom claims such as a role or a plan. - Signature: a hash of the header and payload computed with a secret (HMAC) or a private key (RSA, ECDSA). It proves the content was not altered.
Here is a decoded payload: {"sub":"user_42","role":"editor","exp":1767225600}. Anyone can read it, because Base64URL is an encoding, not encryption. Only the signature protects its integrity.
How authentication with a JWT works
- The user sends credentials to the login endpoint.
- The server checks them and returns a signed JWT, often with a short lifetime of 5 to 15 minutes.
- The client sends the token in the
Authorization: Bearer <token>header on each request. - The server verifies the signature and the
expclaim, then serves the request. - When the token expires, a longer-lived refresh token is exchanged for a new one.
JWTs are frequently used as the access token inside an OAuth 2.0 or OpenID Connect flow, which is why the two terms are often confused. OAuth is the authorization framework, while a JWT is one possible token format.
JWT vs session cookies
| Criterion | JWT | Server session cookie |
|---|---|---|
| State | Stateless, data inside the token | Stateful, session stored server-side |
| Scaling | Easy across many servers or APIs | Needs a shared session store |
| Revocation | Hard before expiry | Immediate, delete the session |
| Best fit | APIs, mobile apps, microservices | Classic server-rendered sites |
Security best practices and common pitfalls
- Never put sensitive data (passwords, personal data) in the payload, since it is readable by anyone.
- Use short expiration times and refresh tokens, because a stolen JWT stays valid until it expires.
- Always verify the signature and reject the
nonealgorithm; pin the expected algorithm on the server. - Prefer an
HttpOnly,Securecookie over localStorage to limit exposure to cross-site scripting. - Keep signing keys in a secret manager and rotate them regularly.
A JWT is a good fit when several services must trust the same identity. It is a poor fit when you need instant revocation, in which case a server-side session or a token denylist is safer.
JWT at BeBranded
On the custom web applications we build, authentication is designed early: we choose between sessions and JWT-based access tokens depending on the architecture, and we rely on proven providers such as Supabase, Firebase or Xano rather than writing token logic from scratch. Discover how our team approaches secure product builds on our Web apps service.