Decode a JSON web token.

The token is decoded in this page, and nothing here sends or stores it. A production token is still a live credential, so use an expired or test token when you can.

No. The signature is shown without being checked. Verification needs the signing secret or public key, and that belongs on your server.

The decoder compares the exp claim with the clock on your computer. If that time has passed, the token shows as expired. A token without exp shows no expiry.

Yes. Decoding needs no account and costs nothing, and there is no limit on how many tokens you read.

No. The decoder takes Bearer off the front, in any capitalisation, and removes spaces and line breaks, so a token copied from a header or a wrapped log line reads as it is.

exp, iat and nbf, when they are numbers. Each shows as a date in your local time. exp says expired or not expired, nbf says in effect or not valid yet, and iat shows the date alone.

Five segments mean an encrypted JWE, and the decoder says so rather than trying to read it. Decrypting one needs the key it was encrypted with.

The header or payload holds a character outside the base64url alphabet, or has the wrong length, which usually means part of the token was lost in copying. The message names the segment that failed.

A JWT's header and payload are JSON objects. If one decodes to something else, the decoder says that segment is not valid JSON rather than guessing at it.

Yes. The header and the payload each have a Copy button that puts the indented JSON on your clipboard.

No. A signed JWT's payload is only encoded, so anyone who has the token can read it, as this page shows. Keep secrets out of the claims, or use an encrypted token.

No. The token lives in this page while it is open, and nothing is saved in the browser or sent anywhere.

The token's not-before time is still in the future by your computer's clock, so a server checking it would refuse the token until then. If your clock is wrong, the line is wrong too.

Any. The decoder reads the header whatever alg it names, such as HS256, RS256 or ES256, because decoding does not depend on the algorithm. Only verifying the signature would.

Yes, when it is a JWT. OpenID Connect ID tokens are JWTs, and many access tokens are too. An opaque token, a random string with no dots, is not a JWT and gets a message that it has the wrong number of segments.

They are shown in your local time zone, while the token stores seconds since 1 January 1970 in UTC. Someone in another time zone sees the same moment as a different clock time.

No. The decoder reads a token and shows what it says. Changing a claim would need a new signature from the key that signed it.

A token whose header says none carries no signature, and the decoder shows None on this token in its place. Servers should refuse such a token unless they were set up to expect one.

It is shown as the base64url text from the token. That text is the signature's bytes, not something that decodes to readable words.

Yes. The header and payload boxes scroll, so a long payload stays readable, and each has a Copy button for the full JSON.

Carrying claims about a user or a session between services, most often in an Authorization header. The server that receives one checks the signature before it trusts any claim.

It names the kind of token, usually JWT. The decoder shows it with the rest of the header and does not rely on it.

Only numeric time claims get a row, since the standard stores them as seconds. A claim written as a string shows in the payload JSON but gets no date line.