What Is a JWT? How JSON Web Tokens Work

A JSON Web Token (JWT, pronounced jot) is a compact, URL-safe string that carries a set of claims - statements about a subject, such as a user id and an expiry time - plus a signature that lets the receiving server trust those claims. A server issues the token once, and from then on each request that presents the token is authorized without a server-side session lookup. The format is defined in RFC 7519.

What are the three parts of a JWT?

A JWT is three base64url-encoded segments joined by dots: the header, the payload and the signature. The header declares how the token was signed, the payload holds the claims, and the signature proves the first two parts were not tampered with. A typical token looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Every JWT, no matter which algorithm signed it, keeps this dot-separated shape. The first segment decodes to a small JSON header, the second to the claims, and the third is a signature you cannot read back. You can paste any token into the JWT Decoder to see the header and payload in clear text.

How does a JWT prove who you are?

The signature is the part that proves authenticity. With a symmetric algorithm such as HS256, the server signs the token with a secret key it shares with nobody, so when it sees a signature that matches the header and payload it knows it wrote the token itself. With asymmetric algorithms such as RS256 or ES256, a private key signs and a public key verifies, which lets other services validate the token without sharing the private key.

Verification is a strict check: recompute the signature over the header and payload with the expected key and compare it byte-for-byte. Any change to a claim changes the signature, so a tampered token fails. This is why the payload is safe to read - reading it changes nothing, while changing it breaks the signature.

What is a JWT used for?

• Authorization: after a login, the server issues a JWT and the client sends it with each request, so the API knows who the caller is without a session table.
• Information exchange: two parties can share claims such as a user id and a role while the signature guarantees nobody altered them in transit.
• Stateless sessions: because the token carries its own claims, any server in a fleet can authorize a request without shared session storage.

The trade-off is that a valid JWT cannot be easily revoked before it expires. A session can be deleted server-side, but a JWT stays valid until its exp claim passes, so tokens are usually issued with short lifetimes.

Is a JWT encrypted?

No, and this is the most common misunderstanding. A JWT is signed, not encrypted. The header and payload are only base64url-encoded, which is encoding, not encryption - anyone can decode them. If a token carries an email address or a user id, treat it as public data. A different format, JWE (JSON Web Encryption), exists for encrypted tokens, but most JWTs in the wild are plain signed JWTs.

What is the difference between a JWT and a session cookie?

A classic session stores a record on the server keyed by an opaque id, and the client sends only that id. A JWT moves the session data into the token, so the server does no lookup. That removes a database round trip per request and makes horizontal scaling simpler, because any instance can verify the token. The cost is revocation: killing a session is one delete on the server, while killing a JWT requires rejecting it at the edge or waiting for expiry.

What is the difference between JWT and OAuth?

OAuth 2.0 is an authorization framework that describes how a client gets permission to act on behalf of a user, with roles such as authorization server and resource server. JWT is just a token format. They sit on different layers: OAuth can use JWTs for its access tokens, and JWT can be used without OAuth, for example when an internal service signs its own claims. Many production setups are both, which is why the two terms show up together.

When should you avoid a JWT?

• When you need instant revocation, such as banning a user or logging out everywhere at once.
• When the token would hold sensitive data, because the payload is readable by anyone holding the token.
• When the token would become large, because every request pays for the full payload on the wire.

For short-lived authorization where revoking at the next refresh is acceptable, a JWT is a solid fit. For long-lived state you need to kill on demand, a server-side session is simpler.

How do you inspect a JWT safely?

Decode the header and payload with the JWT Decoder, and verify the token with the JWT Validator, which checks the signature, the exp claim and the algorithm. Decoding shows you the claims; validating tells you whether to trust them, and the two are separate steps.