JWT Decoder

This tool reads a token. It does not check it. The signature, the third part after the second dot, is ignored completely. To show this, take the sample token, replace its signature with AAAA, and decode it again: the header and payload come out exactly the same. Delete the signature entirely and you still get the same output.

Anyone can build a token with any claims they like, such as "role": "admin", and it will decode here without complaint. Only a server holding the right key can tell a genuine token from a forged one. Use this page to see what a token says, never to decide whether to trust it.

The tool splits the token at the dots, decodes the first two parts from base64url, and pretty-prints them as JSON under // HEADER and // PAYLOAD. The built-in sample decodes to:

Non-English text in claims, such as accented names or emoji, decodes correctly. Spaces and line breaks around the token are trimmed.

• "at least two dot-separated parts": you pasted only part of the token, or something that isn't a JWT.
• "Could not decode token": usually a leftover Bearer prefix from an Authorization header. Delete it and paste only the token.
• Unreadable characters instead of JSON: the text has dots in it but isn't base64url-encoded JSON, or it's an encrypted token (see the FAQ).

When a request fails with 401 or 403, decode the token and work through the payload:

1. Expiry. Copy the exp number into a Unix timestamp converter. It is in seconds. If it's in the past, the client needs to refresh the token.
2. Audience and issuer. Compare aud and iss with the values your API is configured to expect. A token issued by a staging environment can fail against production for this reason.
3. Algorithm and key ID. Check that alg and kid in the header match what the server accepts. A rotated signing key shows up as an unfamiliar kid.
4. Permissions. Look for the scope or role claim your endpoint checks, and its exact spelling and case.

If everything looks right, the problem is probably the signature or the clock, which only the server's own logs can confirm.

Decoding runs in your browser and nothing is uploaded. Even so, a live access token works for anyone who holds it until it expires. Don't paste one into tickets, chat threads or screenshots. For debugging, use an expired token or one from a test account.

Remember that the payload is only encoded, not hidden. Whatever you can read here, anyone who intercepts the token can read too, so email addresses and internal IDs in claims are visible to them.