What is JWT (JSON Web Token)?

Anatomy: header.payload.signature

A JWT (the spec suggests pronouncing it "jot") is three Base64url-encoded segments joined by dots, so on the wire it looks like xxxxx.yyyyy.zzzzz. Decoded, the parts look like this:

// Header: algorithm and token type
{ "alg": "ES256", "typ": "JWT", "kid": "2026-key-1" }

// Payload: the claims
{
  "iss": "https://auth.example.com",
  "sub": "user_123",
  "aud": "https://api.example.com",
  "iat": 1767222000,
  "exp": 1767225600,
  "scope": "invoices:read"
}

// Signature
ECDSA_SHA256( base64url(header) + "." + base64url(payload), private_key )

iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at) and jti (unique ID) are the registered claims from RFC 7519. Times are Unix seconds — the token above is valid for one hour. Applications add their own claims alongside them.

Signed is not the same as secret

When people say "JWT" they almost always mean a JWS (JSON Web Signature) token. Base64url is an encoding, not encryption, so anyone who obtains the token can read the payload. The signature only guarantees integrity and origin. If the contents themselves must be confidential, there is JWE (JSON Web Encryption) — though the simpler fix is usually not to put confidential data in the token at all.

Signing comes in two flavours. With a symmetric algorithm such as HS256, one shared secret both signs and verifies, so every service that can verify tokens can also mint them. With asymmetric algorithms such as RS256 or ES256, only the issuer holds the private key and other services verify with a public key, typically fetched from a JWKS endpoint. When several services verify tokens, asymmetric signing is the safer default.

Validating a token

1. Verify the signature against an algorithm allowlist you configure — never trust the alg value in the token's own header.
2. Check exp and, if present, nbf, allowing a few seconds of clock skew.
3. Confirm iss is the expected issuer and aud names your service.
4. Only then use scopes or roles in the payload to make an authorization decision.

Common mistakes

• Accepting alg: none: the spec defines none for unsecured tokens. A library or configuration that accepts it lets an attacker strip the signature and rewrite the payload. The related "algorithm confusion" attack tricks a verifier into using an RS256 public key as an HS256 secret. Both are covered in the JWT Best Current Practices (RFC 8725).
• Putting sensitive data in the payload: national ID numbers, internal identifiers or personal details end up in logs, browser history and third-party tools along with the token.
• Long lifetimes with no way to revoke: a stateless JWT cannot be withdrawn before it expires. Keep access tokens short-lived (minutes), rotate refresh tokens on every use, or keep a denylist keyed by jti. If instant logout is a hard requirement, a server-side session may be the better tool.
• Weak HS256 secrets: a short or guessable secret can be brute-forced offline from a single captured token.
• Keeping tokens in localStorage: any XSS bug can read them. An HttpOnly cookie reduces that exposure but brings CSRF protection back into scope.

When JWTs fit

JWTs shine where a recipient benefits from verifying a token locally without calling a central server on each request: OAuth access tokens, OpenID Connect ID tokens and service-to-service calls. For a classic web app behind a single backend, keeping the session server-side after authentication is often simpler and easier to control.