Last updated 28 August 2026
Decoding is not the same as trusting
A JSON Web Token has three parts separated by dots: a header saying which algorithm signed it, a payload carrying the claims, and a signature over the first two. The first two parts are Base64url — encoded, not encrypted — which means the payload is readable by anyone holding the token, including whoever it was issued to. That is by design, and it is why tokens should never carry anything genuinely secret. This tool reads those two parts and reports the standard time claims: issued-at, not-before and expiry. What it deliberately does not do is verify the signature, because that requires a key, and putting a signing key into a web page would defeat the point of having one. Verification belongs on the server that issued the token.
Common questions
Is my token sent anywhere?
No. The decoding happens entirely in your browser using its built-in Base64 support. The token never leaves the page, which matters because a live token is a credential.
Why can't it verify the signature?
Verification needs the secret or public key that signed the token. Anything placed in a web page is visible to everyone who loads it, so a key does not belong here. Decoding shows you the contents; only your server can confirm they are genuine.
Is a JWT encrypted?
No, not in the common case. The header and payload are Base64url encoded, which is reversible by anyone. The signature stops a token being altered, but it does not hide what is inside — so tokens should never carry passwords or sensitive personal data.
What do exp, iat and nbf mean?
They are standard time claims, all counted in seconds since 1 January 1970. Expiry (exp) is when the token stops being valid, issued-at (iat) is when it was created, and not-before (nbf) is the earliest moment it may be used.