A JWT (JSON Web Token, pronounced "jot") is a compact, URL-safe way to represent claims between two parties. In practice, JWTs are the standard format for authentication tokens — the thing your browser stores after you log in and sends with every API request to prove who you are.
What a JWT looks like
A JWT is three Base64URL-encoded strings separated by dots:
The three parts are: Header · Payload · Signature. Each part is independently readable once decoded from Base64URL.
Part 1: The Header
The header describes the token itself — what type it is and which algorithm was used to sign it:
alg is the signing algorithm. HS256 (HMAC-SHA256) is the most common for symmetric signing. RS256 (RSA-SHA256) is used when the signer and verifier are different parties (e.g. an OAuth provider signing tokens that your app verifies).
Part 2: The Payload
The payload contains the claims — statements about the user or the token itself:
Standard claim names (called "registered claims") have short three-letter names to keep tokens compact:
| Claim | Meaning |
|---|---|
sub | Subject — usually the user ID |
iat | Issued at — Unix timestamp when the token was created |
exp | Expiration — Unix timestamp after which the token is invalid |
nbf | Not before — token is not valid before this timestamp |
iss | Issuer — who created the token |
aud | Audience — who the token is intended for |
You can add any custom claims you need — role, email, permissions — alongside the standard ones.
Part 3: The Signature
The signature proves the token has not been tampered with. It is created by taking the encoded header and payload, joining them with a dot, and running them through the signing algorithm with a secret key:
When your server receives a token, it recomputes the signature using the same secret and compares it with the signature on the token. If they match, the token is authentic and unmodified. If even one character of the payload was changed, the signature will not match.
How JWTs are used in practice
- User logs in with username and password
- Server verifies credentials, creates a JWT signed with a secret key, and returns it
- Client stores the JWT (in localStorage, a cookie, or memory)
- Every subsequent API request includes the JWT in the
Authorization: Bearer <token>header - Server verifies the signature on each request — no database lookup needed
When not to use JWTs
JWTs are not always the right choice. Because they are stateless, you cannot revoke a JWT before it expires — once issued, it is valid until exp. If you need instant token revocation (e.g. for logout or account suspension), you either need short expiry times combined with refresh tokens, or a token blocklist — which reintroduces server state.