What's Actually Inside a JWT

A JSON Web Token is three Base64URL-encoded segments joined by dots: header, payload, and signature. Anyone can decode the header and payload; that's by design, they're not encrypted, only signed. The signature is what proves the token hasn't been tampered with, and only the issuing server can verify it.

That distinction matters: decoding a JWT to inspect its claims is completely safe and requires no secret key. Verifying it requires the signing key and should only happen on a trusted server.

What to Check When You Decode a Token

• alg in the header confirms the signing algorithm (HS256, RS256, and so on).
• exp is the expiry timestamp. If it's in the past, the token is dead regardless of signature validity.
• iat is the issued-at time, useful for spotting clock-skew bugs.
• sub and custom claims are the actual identity and permissions the token grants.

Why Not Just Use Any Online JWT Debugger?

A production JWT often contains a real user ID, session scope, or internal role claim. Pasting it into an unfamiliar website means that site's server sees the full token, even if it "only decodes," and you have no way to verify that claim. The JWT Decoder & Inspector runs the Base64URL decode entirely in your browser tab; the token is never transmitted anywhere, which is what makes it safe to use with tokens from a live staging or production session.

A Debugging Checklist

1. Decode the token and confirm the alg matches what your server issues.
2. Check the expiry status. A huge share of random 401 errors trace back to an expired token being reused by a stale client.
3. Confirm the claims (sub, custom roles, scopes) match what you expect for that user.
4. If something looks wrong, fix it server-side. Never edit a token's payload and expect the signature to still validate.

Pair this with the Hash Generator if you're also verifying checksums on the secrets used to sign your tokens.