JWT Decoder
Inspect Header and Payload, expiry status and claim meanings
Last updated: 2026-10-10
About this tool
A JWT’s contents are Base64URL-encoded, not encrypted - anyone who gets hold of one can open it and see what is inside, which is exactly the capability you need when debugging. This tool unfolds all three parts in full and converts the iat, exp and nbf time claims into readable dates while judging whether the token is currently valid, saving you the manual timestamp arithmetic.
Features
All three parts decoded
Header and Payload are shown as formatted JSON and the Signature is given in hex for reference, with each part copyable individually.
Time claims visualised
iat (issued at), exp (expires at) and nbf (not before) are converted automatically from Unix seconds into readable dates, with relative descriptions such as “expires in 2 hours”.
Validity status
Combining nbf and exp yields one of four states - within its validity period, expired, not yet valid, or no expiry set - so a login problem can be identified as time-related at a glance.
Unsafe configuration warnings
An alg of none means the token has no signature and its contents can be altered at will. That is a serious security weakness, so the tool warns explicitly rather than merely displaying the value.
Correct UTF-8 handling
Base64URL is decoded to bytes first and then read as UTF-8, so Chinese characters or emoji in the payload do not come out as mojibake - a pitfall many simple implementations fall into.
Forgiving input
A pasted Bearer prefix, extra spaces or line breaks are all handled. A wrong three-part structure, invalid Base64 or malformed JSON each produce a specific reason.
How to use
- 1
Paste the token
Copy the full JWT from your browser dev tools or a log. A Bearer prefix is optional; the tool recognises it either way.
- 2
Read the three parts
The Header holds the signing algorithm and type, and the Payload holds the actual business data carried - both parts are readable plaintext.
- 3
Check the time claims
If a user reports “expired right after logging in”, look at exp and the relative time first; if the report is “the token does not work”, check whether nbf is still in the future.
- 4
Inspect the algorithm setting
Confirm that alg is the algorithm you expect. Seeing none, or an unexpected algorithm name, suggests a possible server-side configuration problem.
Options
- Header
- Usually carries alg (the signing algorithm, such as HS256 or RS256) and typ (the type, normally JWT). It may also carry kid to indicate which key was used.
- Payload
- Carries the actual data as a set of claims. Standard claims have defined meanings and you can add arbitrary custom fields, but remember this part is plaintext - never put sensitive information in it.
- Signature
- Produced by signing the first two parts with the algorithm named in the Header. Its purpose is tamper detection, and verifying it requires the key - which is why this tool displays it but does not verify.
- iss (issuer)
- Identifies who issued the token, usually the server’s domain or application name. Verification should confirm it matches what you expect.
- sub (subject)
- Identifies whom the token is about, usually a user ID. Note that it need not equal the user ID - that depends on the issuer’s convention.
- aud (audience)
- Identifies who the token is intended for, preventing a token issued by service A from being used against service B.
- exp (expires at)
- A Unix seconds timestamp after which the token is invalid. Note this is declared by the issuer and does not guarantee the server actually enforces it.
- nbf (not before)
- A Unix seconds timestamp before which the token should not be accepted. Used to avoid false rejections caused by clock skew.
- iat (issued at)
- A Unix seconds timestamp recording when the token was created. Useful for judging how fresh it is, but not the same as the expiry time.
- jti (JWT ID)
- A unique identifier for the token, often used to implement single-use tokens or revocation lists.
Common use cases
- Investigating a token reported as expired right after login
- Confirming which user information a server-issued token carries
- Checking that alg is the expected algorithm and not a mistaken none
- Verifying that the exp duration matches the product’s login-retention policy
- Reading issuer, audience and other routing information out of someone else’s token
- Inspecting the three parts visually while learning how JWTs are structured
- Confirming that no sensitive fields were accidentally leaked into a token
FAQ
Questions you may have about this tool
Is a JWT encrypted? Why can I see its contents?
It is not encrypted, merely Base64URL-encoded. Encoding is just a different way of writing the data and anyone can reverse it; encryption is what requires a key. A JWT’s security comes from its signature - the signature guarantees the contents have not been tampered with but **does not keep them secret**. So never put passwords, ID numbers or other sensitive information in the payload.
Why does this tool not verify the signature?
Because verification needs the key, and a key should never appear in a browser. More to the point, if a tool asked you to enter the key, the key would already have been disclosed to a third party. So this tool deliberately only decodes. Verify on the server with a trusted library.
What is alg=none and why is it dangerous?
It means the token carries no signature at all. If a server implementation is lax - accepting none by mistake - an attacker can simply change alg to none, edit the payload and forge a token for any identity. It is one of the most famous vulnerabilities in JWT’s history, and production systems must reject none explicitly.
If exp has not passed, is the token definitely usable?
Not necessarily. exp is only the validity the token declares about itself; the server may not check it, or may apply other rules such as a revocation list or a change in user status. Clock differences between server and client can also cause misjudgements. This tool’s status is indicative only - the real answer lies in the server’s behaviour.
What is the difference between HS256 and RS256?
HS256 is symmetric: the same key signs and verifies. RS256 is asymmetric: a private key signs and a public key verifies. For multi-service setups RS256 fits better, because a verifier needs only the public key and does not have to hold a private key capable of signing. Which to choose depends on your architecture, but in all cases the key must stay out of the front end.
Are the payload fields fixed?
No. Only iss, sub, aud, exp, nbf, iat and jti are standard claims; everything else is defined by the issuer. Even the standard claims are all optional - a JWT payload can legitimately be an empty object, {}. So never assume a particular field is present.
Why is the decoded content not a JSON object?
It suggests this is probably not a normal JWT, or that the token was truncated while being copied. A standard Header and Payload are both JSON objects (starting with {); if what comes out is an array, a string, or a parse failure, the token is usually incomplete or has been substituted.
Is pasting a token into an online tool risky?
Yes. Although this tool parses entirely locally in your browser and sends nothing (it works with the network disconnected), the risk is that you cannot easily verify that promise for any online tool. Our advice is therefore: do not paste real production tokens, use a test-environment token instead.