What is a JWT (JSON Web Token)?
⏱ 2 min readA JWT (JSON Web Token) is a compact, self-contained way to pass verified claims — like 'this is user 42 and the session expires at noon' — between systems. It looks like gibberish, but it's just three Base64URL-encoded parts joined by dots.
The three parts
header.payload.signature — split any JWT at the dots and you get:
- Header — JSON naming the signing algorithm, e.g. {"alg": "HS256", "typ": "JWT"}.
- Payload — JSON of claims: registered ones like sub (subject), iss (issuer), exp (expiry), iat (issued-at), plus anything custom.
- Signature — a cryptographic signature over the first two parts, made with a secret (HMAC) or private key (RSA/ECDSA).
Signed, not encrypted — the critical distinction
The header and payload are merely Base64URL-encoded: anyone holding the token can read them in milliseconds. The signature stops tampering, not reading — change one character of the payload and verification fails. Never put passwords, card numbers or anything confidential inside a JWT payload.
How verification works
The receiving server recomputes the signature from the header and payload using the shared secret (or the issuer's public key) and compares it to the token's third part, then checks claims like exp. This must happen server-side on every request — decoding without verifying, as browser tools do, proves nothing about authenticity.
Where you meet JWTs
API authentication (the Authorization: Bearer header), OAuth 2.0 and OpenID Connect ID tokens, single sign-on, and service-to-service auth in microservices. Short expiry plus a refresh-token flow is the standard pattern for limiting the damage of a leaked token.
Frequently asked questions
Can someone read my JWT if they intercept it?
Yes — the payload is readable by anyone. HTTPS protects it in transit, and the signature prevents modification, but confidentiality of the contents is not a JWT feature.
What happens if I edit the payload?
The signature no longer matches, and any properly verifying server rejects the token. That tamper-evidence is the whole point of the signature.
Where should a browser app store JWTs?
An httpOnly, Secure cookie avoids JavaScript-readable storage (XSS risk) but needs CSRF defenses; localStorage avoids CSRF but is exposed to XSS. There is no perfect answer — minimize token lifetime either way.