JWT Decoder and Verifier

It is a token with three parts separated by dots: header, payload and signature. The header states which algorithm signed it; the payload carries the data, usually who the user is, who issued the token and when it expires; and the signature lets you verify nobody modified it. The first two parts are just URL-safe Base64, so anyone can read them. The third is the only one protecting anything, and only whoever holds the key can verify it.

Decoding happens entirely in your browser: the token is not sent to any server and not stored. That said, the healthy habit with any decoder is not to paste production tokens that are still valid, because a JWT is a credential: whoever holds it can use it until it expires. To debug, use a token from a test environment or one that already expired.

No. The payload is not encrypted, only Base64-encoded, and this very page proves it: it is read with no key at all. Never put passwords, card numbers, sensitive personal data or anything you would not want the token holder to see. What the signature guarantees is that the payload has not been altered, not that it is secret.

They are the three time fields in the standard and all three are Unix timestamps in seconds. `exp` is when the token expires, `iat` when it was issued and `nbf` from when it becomes valid. This tool translates them into readable dates and tells you whether the token is current or expired. The most common mistake with them is sending milliseconds: if your token expires in 1970 or in the year 58000, that is the problem.

Because verifying the signature requires the secret or public key it was signed with, and that secret must never leave your server under any circumstance. Any page asking you to paste it in order to "validate" the token is asking for the key to your system. What can be done without keys, and is what happens here, is reading the payload, checking the structure and warning you if it has expired.

It is a value allowed by the standard meaning "this token carries no signature". It existed for cases where integrity is guaranteed another way, but it became a classic vulnerability: an attacker changes the header algorithm to none, deletes the signature, edits the payload freely and a badly configured library accepts it. Seeing `alg: none` in a real token is an alarm. Modern libraries reject it by default and you should always pin the expected algorithm on the server.