Decode a JWT

No — and for this page that is the entire point rather than a feature. A JWT is usually a live credential: whoever holds it can act as you until it expires. Pasting one into an online decoder that posts it to a server hands over a working key, and no promise about not logging can undo that. This decoder is plain JavaScript in the page you are looking at. Nothing is uploaded, nothing is logged, no request is made. Yes. Once the page has loaded, turn off your Wi-Fi and it works exactly the same. That is the simplest way to confirm the privacy claim for yourself rather than taking our word for it — and with the developer tools open on the Network tab, you can watch that nothing is sent.

No, and no online decoder honestly can without your signing key. Decoding and verifying are completely different operations. Decoding just un-Base64s the token — anyone can do it to any token, and it proves nothing at all about whether the token is genuine. Verifying means recomputing the signature with the secret or public key that signed it, and that key should never be pasted into a website. What you see here is what the token CLAIMS. Whether those claims are trustworthy is a question only your server, holding the key, can answer.

Yes — completely, and this catches people out. A JWT is signed, not encrypted. The header and payload are Base64, which is an encoding with no secret in it, so anyone who intercepts the token can read every claim inside it. The signature stops them CHANGING the token; it does nothing to stop them READING it. Never put anything confidential in a JWT payload: no passwords, no card numbers, no personal data you would not put on a postcard.

That the token says it is unsigned, and it is one of the most serious findings this page reports. `alg: none` is a documented authentication bypass: an attacker takes a real token, changes the payload to say they are an administrator, sets the algorithm to "none", removes the signature, and a library that trusts the header accepts it. Every serious JWT library now blocks this by default, but implementations that trust `alg` still exist. A token arriving with `alg: none` should be treated as an attack until proven otherwise.

It is done for you. `exp`, `iat` and `nbf` are Unix timestamps — seconds since 1970 — which are unreadable as raw numbers. Each is shown as a real date in your own timezone, with how long ago or how long from now, and an expired token is stated plainly rather than left for you to work out. A token with no `exp` at all is flagged too: a JWT that never expires cannot be revoked by expiry, and stays valid for as long as the signing key does.

Then it is a JWE — encrypted rather than merely signed — and its contents genuinely cannot be read without the decryption key. The page recognises the shape and tells you so instead of showing you nonsense. Five parts means the payload is real ciphertext; there is nothing to decode.

The registered ones are: `iss` who issued it, `sub` who it is about (usually a user ID), `aud` who it is for, `exp` when it expires, `nbf` not valid before, `iat` when it was issued, and `jti` a unique ID for the token. Everything else is custom to whoever built the system. Each registered claim is labelled with its meaning in the output, so you do not need to remember which three-letter abbreviation is which.