⌘K

Security

JWT

A JSON Web Token (JWT) is a compact, signed token that carries JSON claims about a user or client so a server can verify identity without a database lookup.

Updated 12 Aug 2026

Three segments, two dots

A JWT is three URL-safe Base64 segments joined by dots. The header names the signing algorithm, the payload holds the claims, and the signature proves the first two parts were produced by someone holding the key and have not been altered since.

Standard claims

ClaimMeaning
subSubject — who the token is about
issIssuer — who created it
audAudience — who it is intended for
expExpiry timestamp; the token must be rejected after it
iatIssued-at timestamp
nbfNot valid before this time

Signed, not secret

The payload is encoded, not encrypted. Anyone holding the token can read every claim. Never put passwords, card numbers or personal data in a JWT.

Verification means recomputing the signature with the expected algorithm and key, then checking exp, iss and aud. Two classic failures are trusting the alg header from the token itself — which enabled the infamous "alg: none" bypass — and decoding a token without verifying it at all.

Tokens versus sessions

A session id is a meaningless key looked up server-side, so revoking it is instant. A JWT is self-contained and needs no lookup, which scales well but makes revocation hard: until it expires, a stolen token stays valid. The usual compromise is short-lived access tokens plus a revocable refresh token.

JWT Decoder

Inspect header, payload and expiry locally — the token never leaves your browser.

Try JWT Decoder

Characteristics

  • Three dot-separated segments: header, payload, signature
  • Encoded with URL-safe Base64, so tokens fit in headers and URLs
  • Signed with HMAC (HS256) or a private key (RS256, ES256)
  • Self-contained — claims travel with the request

Common uses

  • Stateless API authentication with bearer tokens
  • Single sign-on and OpenID Connect identity tokens
  • Short-lived signed links such as password resets
  • Passing verified user context between microservices

Advantages

  • No server-side session store required
  • Works cleanly across services and domains
  • Claims are verifiable offline with a public key
  • Compact enough for HTTP headers

Limitations

  • Cannot be revoked before expiry without extra infrastructure
  • Payload is readable by anyone holding the token
  • Large claim sets add weight to every request
  • Easy to misconfigure — algorithm confusion and skipped verification are common

Examples

The decoded header and payload of a typical access token
// header
{ "alg": "HS256", "typ": "JWT" }

// payload
{
  "sub": "4821",
  "role": "editor",
  "iss": "https://api.example.com",
  "iat": 1771200000,
  "exp": 1771203600
}

Frequently asked questions

What is a JWT used for?

Proving who a caller is on each API request without the server keeping session state.

Is a JWT encrypted?

Not by default. It is signed and Base64-encoded, so claims are readable by anyone who holds it.

How do I revoke a JWT?

Keep access tokens short-lived and revoke the refresh token, or maintain a deny list checked on each request.

Where should a JWT be stored in a browser?

An httpOnly, secure cookie is safest; localStorage exposes the token to any script running on the page.

What does 'alg: none' mean?

An unsigned token. Servers must reject it and always enforce the algorithm they expect.

JWT or session cookie?

Sessions suit a single application needing instant revocation; JWTs suit distributed APIs and SSO.

Related terms

All terms

Related tools

Related guides

All guides