The three parts
A JWT (JSON Web Token) is three Base64URL-encoded segments separated by dots: header.payload.signature. The header names the signing algorithm, the payload holds claims — data about the user or session, such as expiry, subject, or custom fields — and the signature proves the token has not been altered since it was issued.
It is encoded, not encrypted
This is the detail most often misunderstood: the header and payload are Base64URL-encoded, not encrypted. Anyone holding the token can decode and read the payload — decoding it costs nothing more than the JWT Decoder does. The signature does not hide the contents; it only proves they were not tampered with after signing. Never put a secret, password, or anything sensitive directly in a JWT payload.
How the signature works
With a symmetric algorithm like HS256, the server signs the token with a secret key and verifies incoming tokens with that same key. With an asymmetric algorithm like RS256, the server signs with a private key and anyone can verify with the corresponding public key — useful when multiple services need to verify tokens without sharing a single secret.
Where JWTs fit in authentication
A typical flow: a user logs in, the server issues a signed JWT, the client stores it and sends it with subsequent requests (usually as an Authorization: Bearer header), and the server verifies the signature and checks the expiry claim on each request instead of looking up a session in a database. This is why JWTs are popular for stateless APIs and microservices.
Common pitfalls
- Storing a JWT in localStorage exposes it to XSS; an httpOnly cookie is usually safer.
- Skipping expiry checks means a stolen token works forever.
- Using "none" as the algorithm skips signature verification entirely; reputable libraries reject it by default, but it is worth confirming.
- Trusting the payload without verifying the signature first defeats the point of signing it.
Working with JWTs
To inspect a token you have received, paste it into the JWT Decoder to see the header and payload without touching your own signing key. To create one for testing, the JWT Generator builds an HS256 token from a header, payload, and secret you supply. Debugging an OAuth flow instead? The OAuth Token Inspector breaks down access and ID tokens the same way.
Quick FAQ
Can I trust the data inside a JWT without checking the signature?
No. Anyone can construct a JWT-shaped string with arbitrary claims. The signature is what proves the claims came from a party holding the signing key, so always verify it server-side before trusting the payload.
Do JWTs expire automatically?
Only if the payload includes an exp (expiration) claim and whatever verifies the token actually checks it. The token format itself does not enforce expiry.
Is a JWT the same as an API key?
No. An API key is typically an opaque, long-lived identifier looked up server-side. A JWT is self-contained and verifiable without a lookup, and is usually short-lived by design.