JWT decoder
Splits a JSON Web Token into its header and payload, turns the validity timestamps into readable dates and flags risky settings. The token never leaves your browser.
How to use it
- Copy the token – for example from the Authorization header in your browser's developer tools, from a log or from a config file. You don't need to remove the Bearer prefix.
- Paste it into the box and click Decode token.
- Check the overview: the algorithm, whether the token is currently valid, and the issue and expiry times in UTC and your local time.
- Read through the warnings and, if you need to, copy the header or payload as formatted JSON into a ticket.
How it works
A JWT (JSON Web Token) is a short string that applications use to pass information about a signed-in user – typically in an Authorization: Bearer … header. A signed token has three parts separated by dots: the header (the signing algorithm), the payload (the claims about the user and the token's validity) and the signature. The first two parts are only base64url-encoded, so anyone can read them.
In the overview, the tool explains the registered claims defined in RFC 7519:
- iss – who issued the token, sub – who it is about, aud – who it is intended for, jti – a unique token ID.
- iat – when it was issued, nbf – when it becomes valid, exp – when it expires. These are seconds since 1 January 1970 UTC; the tool converts them to dates and compares them with your computer's clock.
It also flags settings that the best current practices in RFC 8725 warn against:
- alg "none" – the token is unsigned and anyone can change it. An application must not accept it.
- A missing signature on a token that claims to be signed.
- HMAC (HS256/384/512) – safe only with a long random key, never with a password.
- A key in the header (
jwk) or a pointer to one (jku,x5u) – an application should only use keys it trusts itself. - No expiry, or a very long one – a leaked token can then be misused for a long time.
The tool does not verify the signature. It is handy for debugging sign-in flows, for inspecting a token found in a log, or during an incident to find out who a token was issued to and for how long.
FAQ
Is my token sent anywhere?
No. A script decodes it right in your browser; nothing is sent to a server or stored. A valid token is still a credential, though – don't paste it into tools you don't trust, and don't share it in tickets or chat.
Does the tool verify the signature?
No. Verification needs the issuer's secret or public key. The tool only shows what the token contains. A payload that looks right doesn't make the token genuine – that is the application's job to check.
Is the content of a JWT secret?
A regular signed JWT (three parts separated by dots) is not encrypted – the payload is merely encoded, and anyone who has the token can read it. That's why passwords and sensitive personal data don't belong in it. An encrypted token (JWE) has five parts; without the key, the tool can show only its header.
Why does the tool warn about HS256?
HS256 signs with a shared secret key. If that key is a weak password, an attacker can brute-force it from a single leaked token and then mint any token they like. Using HS256 isn't a mistake in itself – the note is a reminder.
Sources
Updated