JWT Decoder

A login bug hands you a Bearer token and you need to see the claims. JWT Decoder shows the header and payload. It does not prove the token is genuine.

Three parts, no signature check

Paste a token with exactly two dots. The first part is the header and the second is the payload. Both are base64url, turned back into JSON. The third part is printed as the signature string and is not checked against a key. If exp is already in the past, you get a warning that the token is expired. If nbf is still in the future, you get a warning that it is not yet valid. A token that is not three parts fails before any JSON is shown. /blog/how-to-decode-a-jwt-token explains why reading claims is not the same as verifying them.

What you can learn, and what you cannot

You can see alg, the subject, the expiry, and whatever other claims the issuer put in the payload. You cannot see whether the signature matches the secret or the public key. An alg of none, or a token you edited by hand, still decodes. JWT Encoder builds a demo token. Base64 Decoder is for a single standard-alphabet string, not a three-part token. URL Decoder is for percent-encoding. JSON Formatter pretty-prints JSON you already have. None of those checks a signature either.

When you should not paste it here

A refresh token or a production access token is a credential. Decode it on a machine you trust, copy the claim you need, and clear the box. Do not screenshot the whole token into a ticket. This decode stays in the browser. It does not store the token and it does not call the issuer. Close the tab if the machine is shared. A warning about expiry does not delete the token from the issuer.