JWT Decoder

A JWT is three Base64url-encoded sections joined by dots: header, payload and signature. The header names the signing algorithm. The payload holds the claims — who the token is about, who issued it, when it expires, plus whatever custom fields your application added. The signature is a cryptographic proof that the first two parts have not been altered.

The critical thing to internalise is that **the payload is not encrypted**. It is ordinary Base64, which anyone holding the token can read in seconds — this page does exactly that, locally. Developers regularly put email addresses, user IDs, roles and internal identifiers into a JWT payload assuming it is opaque. It is not. A signed JWT guarantees integrity, not confidentiality. If a value must stay secret from the token's holder, it does not belong in a JWT.

That is also why this tool does not verify signatures. Verification needs the shared secret or the public key, and pasting a signing secret into any website hands over the ability to mint valid tokens for your system. No web page should ask for that, so this one does not. If you need verification, do it in your own code or with a local CLI.

The expiry check is the reason most people decode a token by hand. The `exp` claim is a Unix timestamp in seconds — not milliseconds, which is a classic bug when generating tokens from JavaScript, where `Date.now()` returns milliseconds and produces tokens valid for roughly fifty thousand years. This tool converts `exp`, `iat` and `nbf` into readable UTC timestamps and tells you how long is left, or how long ago it lapsed.

One security note worth carrying away: if a token's header says `"alg": "none"`, treat it as unsigned and untrusted. Accepting such tokens was a well-known vulnerability in early JWT libraries, and any implementation that still allows it is broken.