About this tool
When an authenticated API call fails with 401 or 403, the first question is what the token actually says: who it was issued to, for which audience, with which roles, and whether it has expired. This decoder splits the token, decodes the Base64URL header and payload, and shows the registered claims with exp, iat and nbf converted to dates and relative times. It also flags settings worth a security test, such as alg "none", embedded keys or remote key URLs. It does not verify the signature: that needs the secret or public key, and decoded claims alone prove nothing.
How to use it
- Paste the token. A leading “Bearer ” from an Authorization header is removed automatically.
- Check the status banner for expiry, then read the header and payload panels.
- Use the claims table to compare iss, aud and sub with what the API expects.
- Review any warnings, which suggest negative tests to run against your API.
JWT Decoder FAQ
Is it safe to paste a production token here?
Decoding happens entirely in your browser and the token is never sent anywhere, but it is stored in this browser’s local storage for convenience until you click Clear. Treat a live token like a password: prefer test environments and clear it when you are done.
Why does the token show as valid here but the API rejects it?
Expiry is only one check. The server also verifies the signature, issuer, audience, sometimes the not-before time with a clock-skew allowance, and whether the token was revoked. A mismatched aud or iss is a common cause of 401 responses between environments.
What should I test when I see alg “none” or HS256?
Re-send the token with alg set to "none" and the signature removed, and with the payload modified but the original signature kept. A correct API must reject both. For HS256, also make sure the secret is long and random, because weak HMAC secrets can be brute-forced offline from any captured token.