A JWT is encoded, not encrypted
This is the misunderstanding that causes real security incidents. The header and payload of a JWT are Base64URL encoded, which is a transport format, not a protection. Anyone holding the token can read every claim inside it — including whoever picked it out of a log file or a browser's local storage.
Never put a password, an internal identifier you would not publish, or personal data in a payload. The signature guarantees the token has not been altered; it guarantees nothing about who can read it.
Where your token should not be pasted
Most online JWT decoders send the token to their server to decode it. If that token is live, you have just handed a stranger an authenticated session. It is the single most common way a debugging session turns into a breach.
Here the decoding happens in your browser with atob — you can confirm it by opening the network tab and watching nothing leave. That is precisely why the expiry check is useful too: an expired token is harmless, a valid one is a credential.
Frequently asked questions
Is a JWT's content encrypted?
No. Header and payload are only Base64 encoded, so they are readable by anyone. Never store secrets in a JWT.
Does this tool verify the signature?
No. Verifying a signature requires the secret or public key, which should never be pasted into a web page. This tool decodes and reads the expiry.
What do iat and exp mean?
iat is when the token was issued and exp when it expires, both as Unix timestamps in seconds.
Is my token uploaded?
No, it is decoded entirely in your browser.