← Learn

How Do JWTs Work? JSON Web Tokens Explained

Updated 14 May 2026

A JWT is a compact, self-contained token used to securely transmit information between parties. Learn how the three parts work, how HMAC signatures are verified, and when to use — or avoid — JWTs.

The one-sentence explanation

A JWT is a string that looks like gibberish but is actually three Base64url-encoded JSON objects separated by dots — a header, a payload, and a signature — that together let a server verify a claim without storing any state.

What a JWT looks like

A JWT has three parts separated by dots. Each part is Base64url-encoded:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header Payload Signature

The three parts explained

1. Header

The header declares the token type and the signing algorithm. Decoded, it looks like:

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

The payload contains claims — statements about the user or token. Standard claims include:

ClaimNameMeaning
subSubjectWho the token is about (e.g. a user ID)
issIssuerWho issued the token (e.g. your auth server)
expExpiryUnix timestamp after which the token is invalid
iatIssued atUnix timestamp when the token was created
audAudienceWho the token is intended for
Important: The payload is Base64url-encoded, not encrypted. Anyone who holds the token can decode and read it. Never put passwords, credit card numbers, or other secrets in the payload.

3. Signature

The signature proves the token has not been tampered with. For HS256 it is calculated as:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

To verify a token, the server re-runs this calculation with its secret and compares the result to the signature in the token. If they match, the payload has not been modified.

Signing algorithms — HS256 vs RS256

AlgorithmTypeKeyWhen to use
HS256 / HS384 / HS512HMAC (symmetric)Shared secretSingle service that both issues and verifies tokens
RS256 / RS384 / RS512RSA (asymmetric)Private key signs, public key verifiesMultiple services verify tokens but only one issues them
ES256ECDSA (asymmetric)Private key signs, public key verifiesSame as RS256 but smaller key and signature size

The number in the algorithm name refers to the SHA hash size. HS256 uses SHA-256, HS512 uses SHA-512. A larger hash provides more security margin but produces a slightly longer signature.

How JWT authentication works in practice

  1. User logs in with their credentials. The server validates them.
  2. The server creates a JWT with claims like sub (user ID) and exp (expiry), signs it with a secret, and returns it to the client.
  3. The client stores the token (ideally in an HttpOnly cookie) and sends it with every subsequent request in the Authorization: Bearer <token> header.
  4. The server verifies the signature and checks exp. If valid, it trusts the claims in the payload without hitting a database.

This is the key benefit: the server does not need to look up session state on every request. The token is self-contained.

When not to use JWTs

  • You need to invalidate tokens immediately — a JWT is valid until it expires. If a user logs out or is banned, the token remains valid until expiry unless you maintain a deny-list, which negates the stateless benefit.
  • The token is stored in localStorage — any XSS vulnerability on your page can steal a localStorage token. Prefer HttpOnly cookies.
  • The payload contains sensitive data — remember, the payload is readable by anyone who holds the token. Use opaque session IDs instead if you need to keep claims private.
  • Simple single-server applications — if you have one server and a database, a standard session cookie is simpler and just as effective.

Related guides

Decode, verify, and sign JWTs in your browser

Inspect any token instantly — nothing is sent to a server

Open JWT Tool →
How Do JWTs Work? JSON Web Tokens Explained | DataToolkit | DataToolkit