The three parts of a JWT
A JWT is a string with three dot-separated parts: header, payload and signature. The header states the algorithm (for example, HS256 or RS256) and the type. The payload carries the data, called claims, such as the user identifier, the issuer or the dates.
The first two parts are JSON encoded in Base64URL. They are not encrypted: anyone with the token can read them. That is why they must not include passwords or data you do not want to expose.
Dates and state
The iat, exp and nbf claims are dates in seconds since 1970 (Unix time). Snipshed shows them in readable UTC form and compares the expiry with your device clock to indicate whether the token is within its validity, expired or not valid yet.
If your computer’s clock is off, the state can be wrong. A token without exp never expires, something worth reviewing in a security design.
Decoding is not validating
The signature guarantees that the content was not modified and that it was issued by whoever holds the key. Checking it requires that key and must be done on the server receiving the token. A token with an altered signature decodes just the same.
Use the tool to debug an integration, understand what a token claims or prepare a test. Do not use it to decide whether a request can be trusted, and handle real tokens carefully: pasting them in an external site can give someone else access.
- Paste the complete token with its three parts.
- Decode and review algorithm, issuer and user data.
- Look at the issue and expiry dates and the state.
- Remember the signature is not verified; validate it on your server.
Criteria for reviewing and delivering the result
If you work with tokens often, get used to checking three things: the algorithm, the expiry and the audience. A token with a very long expiry, or none, increases the damage if it leaks. Avoid pasting production tokens into external tools and use test tokens in your examples. If you suspect a token has been exposed, revoke it in the service that issued it instead of waiting for it to expire.
Reading a sample token
Select Try example and then Decode token. The example is a test token containing a name, an issue time and an expiry time.
The header with the HS256 algorithm, the payload with the data and the dates in UTC are shown, and the state Expired, because the sample token expired in 2018.
Change one letter of the signature and decode again: it still works, which shows that decoding does not validate. Change one letter of the payload and observe the error or the changed data.
View tool screenshot
