JWT Decoded: What's Actually Inside Your Auth Token

If you've built anything with a modern API, you've seen a JWT. It looks like a wall of random characters — three base64url-encoded sections separated by dots. Most developers just check that login works and move on. But knowing what's inside a JWT — and more importantly, what can go wrong — will make you a better, safer developer.

What a JWT Actually Is

A JSON Web Token has exactly three parts:

header.payload.signature

Each part is base64url-encoded (not encrypted — just encoded). That means anyone with the token can read the header and payload. The signature just proves the token wasn't tampered with.

Part 1: The Header

{
  "alg": "HS256",
  "typ": "JWT"
}

The header tells you two things:

• alg — the signing algorithm (HS256, RS256, ES256, etc.)
• typ — always JWT

Security tip: Watch out for "alg": "none". Some older libraries accepted this as valid, meaning no signature verification. Always validate the algorithm server-side.

Part 2: The Payload (Claims)

This is where the actual data lives. Common claims:

| Claim | Meaning | |-------|---------| | sub | Subject — usually the user ID | | iat | Issued At — Unix timestamp when the token was created | | exp | Expiry — Unix timestamp after which the token is invalid | | nbf | Not Before — token shouldn't be used before this time | | iss | Issuer — who created the token | | aud | Audience — who the token is intended for |

{
  "sub": "user_42",
  "name": "Ayla",
  "iat": 1700000000,
  "exp": 1700003600,
  "role": "admin"
}

Important: The payload is NOT encrypted. If you include sensitive data (passwords, credit card numbers), anyone who intercepts the token can read it. Only put data that's safe to expose.

Part 3: The Signature

The signature is computed like this:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

If you change even one character of the header or payload, the signature won't match. This is how the server knows the token hasn't been tampered with.

You cannot verify the signature client-side without the secret. This is by design — our JWT Decoder only decodes header and payload.

Common JWT Security Mistakes

1. Storing JWTs in localStorage

localStorage is accessible by any JavaScript on the page. If your site has an XSS vulnerability, an attacker can steal every token. Prefer httpOnly cookies for storage.

2. Long expiry times

A JWT with exp set to 30 days is valid for 30 days even if the user's account is compromised. Use short-lived access tokens (15–60 minutes) with refresh tokens.

3. Not checking exp client-side

Your server validates the token, but it's good UX to check expiry client-side too. If exp < Date.now() / 1000, redirect to login before making an API call that will fail.

4. Trusting the payload for authorization without server validation

The payload says the user is an admin. But the client decoded it — what if the user edited it? Always validate the full JWT server-side on every request. Never trust client-decoded claims for access control.

Decode Any JWT Instantly

Use our JWT Decoder to paste any token and see its header, payload, all claims with human-readable timestamps, and live expiry status — all without sending the token anywhere.

It's the fastest way to debug auth issues, inspect tokens during development, or verify what claims your auth provider is actually sending.