JWTJWT Decoder

Reading a token proves nothing about it.

A JWT is three Base64url segments joined by dots. Anyone can decode the middle one, including this page — there is no encryption involved. What makes a token trustworthy is the signature, and verifying that requires the issuer key, which no browser tool has.

So this is for reading claims, not for validating them. If your server is accepting tokens it decoded but did not verify, that is a critical vulnerability, and it is a real one that appears in production code.

Never put anything confidential in a JWT

The payload is readable by anyone holding the token, including the browser it was issued to and anything that logs the request. Internal user IDs are fine. Roles are fine. Email addresses are a judgement call. Anything you would not want in a support ticket does not belong in there.

Reading the claims

exp is expiry as a Unix timestamp, iat is when it was issued, sub identifies the subject, iss the issuer, aud the intended audience.

When an API rejects a token that looks correct, the cause is nearly always one of three things: exp has passed, the clocks on the two servers disagree by enough to matter, or aud does not match what the receiving service expects. Check them in that order.

Editing one

You can change the payload, and any correctly implemented server will reject the result because the signature no longer matches. If a server accepts it, that server has a serious bug — historically including the alg none attack, where a token declaring no algorithm was trusted outright.

On pasting live tokens

Decoding here happens in the page and nothing is transmitted. Be more careful elsewhere: a token pasted into a remote decoder should be treated as compromised, because it usually is a live credential.