What a JWT contains

A JSON Web Token usually has three dot-separated parts: header, payload, and signature. The header describes the token type and signing algorithm. The payload contains claims such as subject, issuer, audience, scope, issued-at time, and expiration time.

The header and payload are base64url encoded, not encrypted. Anyone with the token can decode those two parts and read the claims.

Decode does not mean verify

Decoding a JWT only reveals what the token says. It does not prove that the token was issued by a trusted service, that it has not been modified, or that the signature is valid.

Verification requires the correct signing secret or public key, the expected algorithm, issuer, audience, and application-specific validation rules. A browser-side decoder is useful for inspection, not authorization.

  • Use a decoder to inspect claims while debugging.
  • Use server-side verification before trusting a token.
  • Treat copied production tokens as sensitive credentials.

Understand exp, iat, and nbf

JWT time claims are normally Unix seconds. The exp claim says when the token expires. The iat claim says when it was issued. The nbf claim says the token should not be accepted before that time.

Timezone confusion is common because Unix timestamps are absolute values. A good decoder should show both readable local time and ISO/UTC time so you can compare application logs with user-facing behavior.

Common debugging workflow

When a login session behaves unexpectedly, decode the token and check the issuer, audience, subject, scopes, and time claims. Then compare those values with the backend configuration and the clock on the systems involved.

If a token appears active in the browser but fails on the server, the cause may be signature verification, audience mismatch, issuer mismatch, missing scope, clock skew, or a different token being sent than the one you inspected.

FAQ

Is a JWT secret because it looks encoded?

No. The header and payload are encoded, not encrypted. Do not put secrets in JWT claims unless the token is encrypted with a separate mechanism.

Can I use a JWT after the exp time?

A properly implemented server should reject an expired token. Some systems allow small clock-skew windows, but that is a backend policy decision.

Should I paste production tokens into online tools?

Avoid it. Use local tools when possible, remove sensitive claims, or create a test token that reproduces the same issue.

Use the related tool