A JSON Web Token (JWT), pronounced "jot," is a compact, URL-safe string used to represent a set of claims - typically for authenticating a user or authorizing a request. Instead of a server storing session data, the server issues a signed token that the client sends back with each request, and the server verifies the signature without needing to look anything up.

The Three Parts of a JWT

A JWT is three Base64URL-encoded segments joined by dots: header.payload.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header - identifies the token type and signing algorithm.

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

2. Payload - the actual claims: who the token represents, and any other data.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

3. Signature - a cryptographic signature over the header and payload, computed using a secret (or private key) only the server knows. Anyone can decode the header and payload - they're just Base64, not encrypted - but only the server can produce a valid signature, so the token can't be tampered with undetected.

How JWTs Are Used

  • A user logs in; the server verifies credentials and issues a signed JWT
  • The client stores the token and sends it in the Authorization: Bearer <token> header on future requests
  • The server verifies the signature on each request - no database lookup or session store needed
  • The token typically carries an expiry (exp claim) so it stops being valid after a set time

A Common Misconception

JWTs are signed, not encrypted, by default. Anyone who intercepts a token can decode its header and payload and read the claims in plain text - they just can't modify them without invalidating the signature. Never put passwords, secrets, or other sensitive data directly in a JWT payload.

Inspect a Real JWT

Paste any JWT and see its decoded header, payload and signature instantly.

Open JWT Decoder →