How JWT Authentication Works

A JSON Web Token is three Base64URL-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (like HS256 or RS256) and the token type. The payload holds the claims — the actual data, such as who the user is and when the token expires. The signature is a cryptographic seal over the first two parts, created with a secret or private key the server holds.

Because the first two parts are only encoded, not encrypted, anyone can decode and read them. That's by design: the token is meant to be read by the client and the server alike. What stops tampering isn't secrecy but the signature — change a single character in the payload and the signature no longer matches, so the server rejects it. A JWT is a tamper-evident envelope, not a locked box.

The payload is a small JSON object of claims. Registered claims have standard short names: sub (subject — usually the user ID), iss (issuer), aud (audience), exp (expiration time as a Unix timestamp), and iat (issued-at). Applications add their own claims too, like a role or permission set, so the server can make authorization decisions without a database lookup on every request.

The exp claim is the one to watch. It's a Unix timestamp after which the token is invalid, and it's why sessions expire. Because the payload is readable, you can decode a token and check its exp to see exactly when it dies — useful when debugging a login that keeps dropping. Just remember that a client reading exp is informational; the server independently enforces it during verification.

This is the concept people miss: reading a JWT tells you what it claims, not whether those claims are trustworthy. Verification is a separate step where the server recomputes the signature using its secret (HS256) or the issuer's public key (RS256) and checks it matches, then confirms exp hasn't passed and the issuer and audience are expected. Only after verification should any claim be trusted. A decoder that just splits and Base64-decodes the token has verified nothing.

That leads to a practical safety rule: never paste a real, active token into an online decoder that sends it to a server, because a valid token is a live credential — whoever holds it can impersonate you until it expires. Prefer a decoder that runs entirely in your browser (this one does), or use expired and test tokens. Treat a JWT like a password you can read: harmless to inspect locally, dangerous to hand to a stranger.