How to use it
- Paste the token into JWT. It has three parts separated by dots.
- Read Signing algorithm to see how the token says it is signed.
- Check Expiry. Green means the token is still valid at the time on your device.
- Read Claims and Payload to see who the token is for and what it contains.
What a JWT contains
A JSON Web Token has three parts separated by dots. The first two are JSON objects encoded in base64url: the header says how the token is signed, and the payload holds the claims, which are statements such as who the token is for and when it expires. The third part is the signature.
RFC 7519 defines seven registered claim names: iss, sub, aud, exp, nbf, iat and jti. The table explains each one, and the three time claims are also shown as dates in your language.
Decoding is not verifying
This page only decodes the token. It does not check the signature, because that needs the key the token was signed with, and a verifying key is secret. A decoded token can still be forged, so do not trust a claim only because you can read it here.
To verify a token, your server or library must check the signature with the right key and the algorithm it expects, and it must reject a token whose signature is wrong.
How the expiry is read
The exp claim is a number of seconds since 1 January 1970 at 00:00 UTC. RFC 7519 section 4.1.4 says a token must not be accepted on or after that moment, so at the exact time it already counts as expired.
A token without an exp claim never expires. The page shows that in red, because a token that never expires is a risk worth knowing about.
Worked example: the sample token of RFC 7519
The example in RFC 7519 section 3.1 has the header alg HS256, and the payload iss joe, exp 1300819380 and a custom claim. The exp value is 22 March 2011 at 18:43 UTC, so the page shows the token as expired. The signature is not checked, so the result is the same for any signature.
| Claim | Value | Meaning |
|---|---|---|
| iss | joe | Issuer: who created the token |
| exp | 1300819380 (22 March 2011 at 18:43 UTC) | Expiration time |
| http://example.com/is_root | true | A custom claim |
Frequently asked questions
Is my token sent to a server?
No. The token is decoded in your browser, and the page neither stores nor sends it. You can check this by decoding a token with your internet connection switched off after the page has loaded.
Does this page check that the token is genuine?
No. It reads the header and the claims only. Checking the signature needs the key the token was signed with, which this page never asks for. Your application must make that check.
Why does the page say a token has expired when my application still accepts it?
Your application may allow a grace period, or it may check the expiry with its own clock. The page compares exp with the time on your device, so a wrong device clock can also change the result.
What does the algorithm none mean?
The header says the token has no signature. Anyone can write such a token, so a service must not accept it for anything that matters. The page flags it with a note.
Why does a date show a time I did not expect?
The date is shown in your language and time zone, with the zone name at the end. The number before it is the value stored in the token: seconds since 1970 in UTC.
Can this page read an encrypted token?
No. An encrypted token has five parts, and its contents cannot be read without the key. This page reads only signed tokens, which have three parts.
Sources
- RFC 7519: JSON Web Token (JWT)
- RFC 7518: JSON Web Algorithms, the alg values in section 3.1
- RFC 4648: base64url encoding in section 5
Figures and text last checked on Tuesday, November 10, 2026.