About the jwt decoder
A JSON Web Token is three base64url-encoded parts separated by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. The first two are encoded, not encrypted — anyone holding the token can read them, which is exactly what this page does.
That last point is the one worth internalising. A JWT is not a secret container. If your payload contains something the bearer should not see, it is already visible to them, and no amount of HTTPS changes that. Decoding a token you were issued is not an attack; it is reading something that was always readable.
This tool decodes and does not verify, deliberately. Checking a signature requires the shared secret or the private key, and a page that invites you to paste a signing secret is asking for the one credential that must never leave your infrastructure. Verify on your server, where the key already lives. What you get here is what the token claims, not proof that the claim is true.
The claims table names the registered claims from the specification and renders the time-based ones as dates, because nobody reads epoch seconds. It also tells you whether the token has expired or is not valid yet, which is usually the actual question — a request failing with a 401 is far more often an expired token than a wrong one.
The header gets its own attention because of one value. `alg: none` was legal in the original specification and means the token is unsigned; a verifier that honours it will accept a payload written by anyone. It remains the best-known JWT vulnerability, and it still appears. Any token showing it is flagged here.