JWT Decoder

People usually ask to "decrypt" a JWT, and that word hides a dangerous mistake. There is nothing to decrypt: the payload of a JWT is plain Base64, and anyone who gets the token can read it. The signature protects against forgery, not against reading.

This leads to the most common error: people put a phone number, an email, passport data, or even another token inside, treating the payload as a secret. We search for such fields by name and warn you: a token is a place for identifiers, not for the data itself.

Short names like iss, aud, nbf, and jti get human-readable labels, and time values turn into a plain date and a phrase like "expires in 2 hours" or "expired 5 days ago".

The decoder calls out the things that most often turn out to be a hole:

• alg: none — the token is not signed at all, anyone can forge it, and a server that accepts such a token lets anyone in;
• no exp field — the token lives forever, and one that was stolen once keeps working for good;
• an access token valid for months — that is how refresh tokens live, not access tokens;
• the token is expired or not valid yet.

The decoder shows what is written in the token, but it does not tell you whether the token is genuine. Enter a secret for HS256 or a public key for RS256 and ES256, and we will verify the signature. The answer is unambiguous: the signature matches or it does not. Without a key the decoding still works.

About the safety of the decoding itself

A token is a live pass: whoever holds it gets in under your name. And one general rule worth keeping: if a working token has passed through any online service, it is safer to treat it as compromised and issue a new one.