Log in to almost any modern web app and a JSON Web Token is doing the quiet work of proving who you are. JWTs are the standard way for services to pass authentication and identity claims between parties — compact, self-contained, and verifiable without a database lookup. If you have a token and want to see what is inside it, paste it into our free JWT decoder to inspect its header, payload, and signature.
This guide explains the three-part structure of a JWT, how base64url encoding works, the standard claims you will see in the payload, how signature verification actually proves authenticity, where JWTs get used in real systems, and the security mistakes that turn them into vulnerabilities.
A JWT is three base64url-encoded segments joined by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cThe three parts:
alg, e.g. HS256 or RS256) and the token type (typ: JWT).Decoded, the example above reveals:
// Header
{ "alg": "HS256", "typ": "JWT" }
// Payload
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }The header and payload are JSON, but they are encoded with base64url — a URL-safe variant of base64 that replaces + with -, / with _, and omits the = padding. This makes the token safe to put in URLs, HTTP headers, and cookies without escaping.
Critical point that trips up beginners: base64url is encoding, not encryption. Anyone who holds the token can decode the payload in seconds — that is by design, and it is exactly what our JWT decoder does. Never put secrets, passwords, or sensitive personal data in the payload. The payload is signed for integrity, not encrypted for confidentiality. (There is a separate standard, JWE, for encrypted tokens — but a plain JWT is an open book.)
Claims are just name/value pairs, but a set of registered names have agreed meanings:
iss (issuer) — who created the token, e.g. "https://auth.example.com".sub (subject) — who the token is about, usually a user ID. This is the claim your application logic keys on.aud (audience) — who the token is intended for. A service should reject tokens not addressed to it.exp (expiration) — Unix timestamp after which the token must be rejected. The single most important claim for security.iat (issued at) — when the token was created.nbf (not before) — the token is invalid before this time. Useful for scheduled access.jti (JWT ID) — a unique identifier for the token, used to track or revoke individual tokens.On top of these, applications add custom claims: role: "admin", plan: "pro", email, and so on. Custom claims are convenient — the service reading the token gets user attributes without a database query — but every claim you add makes the token bigger and every byte travels with each request.
The elegance of JWTs is that verification needs no database. The receiving server:
exp in the future, is aud correct, is iss trusted?This is why JWTs scale so well for microservices: any service holding the public key (or shared secret) can verify tokens independently. No central session store, no lookup per request. The trade-off is revocation — a validly signed token stays valid until it expires, which is why short expiration times matter.
Authorization: Bearer header with each request. Stateless and simple.JWTs are safe when used correctly and dangerous when misunderstood. The classic failures:
alg: none attack. Some libraries historically accepted tokens with the algorithm set to none (no signature). Modern libraries reject this, but the lesson stands: always validate the algorithm against an allowlist, never trust the token's own header.exp, aud, and iss is like checking an ID's hologram but not its expiry date.A JWT is a signed envelope for claims: header says how it was sealed, payload says what is asserted, signature proves nobody altered it. That simple design powers authentication across the modern web. Use short expirations, validate every claim, keep secrets out of the payload, and store tokens where scripts cannot reach them.
Have a token you want to inspect? Paste it into our free JWT decoder to see its header, payload claims, and expiration at a glance.
No. A standard JWT (JWS) is signed but not encrypted — the payload is base64url-encoded and readable by anyone holding the token. For confidentiality you need JWE (JSON Web Encryption), a separate standard.
HS256 uses one shared secret for both signing and verification (symmetric). RS256 uses a private key to sign and a public key to verify (asymmetric), so many services can verify tokens without being able to forge them. RS256 is preferred when the signer and verifiers are different parties.
Access tokens: minutes to a few hours. Long-lived sessions should use short access tokens plus rotating refresh tokens, so a leaked access token has a small blast radius.
Not inherently — that is the trade-off of statelessness. Common workarounds include very short expirations, a denylist of token IDs (jti) checked on sensitive operations, or rotating the signing key (which invalidates everything).
