JWT Decoder

How to use

1. Paste the token (with or without the “Bearer ” prefix).
2. Read the decoded header and payload, and the explained claims below them.
3. Check the expiry status, then verify the signature in your own server code before trusting anything in it.

What this tool does

A JWT has three parts separated by dots: a header, a payload and a signature, each Base64URL-encoded. The header and payload are just encoded JSON, so anyone can read them. This tool decodes those two parts, explains registered claims such as exp, iat, nbf, iss, aud and sub, and shows the signature bytes as they are.

Why it matters

When an API call fails with 401 Unauthorized, the first question is usually what the token actually contains: has it expired, is the audience right, which scopes were granted? Decoding answers that in seconds.

Common uses

• Debugging WordPress REST API or headless logins that use JWT authentication plugins.
• Checking when an access token expires and which scopes or roles it carries.
• Confirming the signing algorithm and key ID (kid) a provider uses.

Tips

• Never trust a decoded payload in your application without verifying the signature with the expected key and algorithm.
• Reject tokens whose header says “alg”: “none” unless you explicitly expect unsigned tokens.
• Treat tokens as passwords: anyone holding a valid token can usually act as the user until it expires.

Limitations

• This tool does not verify signatures, so it cannot tell you whether a token is genuine or has been tampered with.
• Encrypted tokens (JWE, five parts) can only show their header; the payload needs the decryption key.
• Expiry status uses your device clock, which may differ slightly from the server that checks the token.

Troubleshooting

• “Not a valid JWT”: make sure you copied the whole token, with exactly two dots, and no quotes around it.
• Strange characters in the payload: the token may be a JWE (encrypted) or a different token format, such as an opaque access token.