The Three-Part Structure You Need to Understand

Every JWT looks like three random strings glued together with dots. That's not random — it's a deliberate structure. The first part is the header, the second is the payload, and the third is the signature.

Each part is Base64Url encoded — not encrypted. Base64Url is just an encoding scheme for safely transmitting binary data as text. Anyone with the token can decode the header and payload. The signature is what prevents tampering, not obscurity.

Decode that header and you get {"alg":"HS256","typ":"JWT"}. Decode the payload and you get your user data. Simple as that.

What Lives Inside the Payload — and What Shouldn't

The payload contains claims — statements about the user and additional metadata. There are three categories of claims you'll encounter:

Registered claims are standardized and understood by all JWT libraries. The important ones are sub (subject/user ID), iat (issued at), exp (expiration), iss (issuer), and aud (audience).

Public claims are custom claims that your application defines. Things like role, email, name, or permissions. These are application-specific.

Private claims are agreed upon between specific parties sharing a token — not registered or public.

Real Developer Scenarios Where JWT Decoding Saves Time

JWT vs Session Tokens — When to Choose Which

Sessions store user state on the server. The client gets a session ID, and the server looks up the state in a database or memory store on every request. JWTs store state in the token itself — the server doesn't need to look anything up.

JWTs work well for stateless APIs, microservices, and mobile apps where you want to avoid server-side session storage. They're also great when multiple services need to verify user identity without calling a central auth server on every request.

Sessions are better when you need instant token revocation. Revoking a JWT before it expires is hard — you either need a blocklist (which makes it stateful again) or very short expiration times. Sessions can be invalidated by simply deleting them from the store.

The Security Mistakes That Keep Appearing in JWT Implementations

After reviewing many codebases, the same mistakes keep showing up. Here are the ones worth watching for:

• Algorithm confusion attacks: Using alg: none or allowing servers to accept any algorithm from the token header. Always verify the algorithm server-side.
• Storing JWTs in localStorage: localStorage is accessible to JavaScript and vulnerable to XSS. HttpOnly cookies are safer for storing auth tokens.
• Overly long expiration: A 30-day JWT with no refresh mechanism is a security risk if the token is stolen. Use short-lived access tokens (15-60 minutes) with refresh tokens.
• Not validating the aud claim: A token issued for service A should not be accepted by service B. Always validate the audience claim.
• Putting sensitive data in the payload: This one bears repeating. The payload is visible to anyone with the token.

Reading the exp and iat Claims Correctly

Both exp (expiration) and iat (issued at) are Unix timestamps — seconds since January 1, 1970. When you see "exp": 1737724800, that's not a date you can read directly.

Convert it: multiply by 1000 to get milliseconds, then pass to new Date() in JavaScript. Our JWT decoder does this automatically and shows you the human-readable date alongside the raw value.

If you're checking token expiry manually: compare the exp value to Math.floor(Date.now() / 1000). If exp is less than the current timestamp, the token has expired. Always check this on the server — never trust client-side expiry checks alone.

JWT in Different Languages and Frameworks