Short answer: paste the token and the header, payload and claim times appear as you type. This page decodes; it cannot verify, because verification needs the issuer's key. The warnings list says what the token claims — signed with alg: none, already expired, missing exp, or an empty signature.
What decoding proves, and what it does not
A JWT is three Base64URL segments: a header, a payload and a signature. Decoding the first two needs no key at all — they are plain JSON encoded for transport, not encrypted. That means the contents of a token are readable by anyone who holds it, including a browser extension, a log aggregator or a screenshot.
Only the signature ties the contents to the issuer. It is computed over the first two segments with the issuer's key, and checking it requires that key or its public half plus the algorithm the issuer chose. This tool has neither, so it never displays "valid" — a status it could not honestly earn.
Reading the claims table
- iss — who minted the token.
- sub — the user or entity the token describes.
- aud — who is supposed to accept it. A verifier must check it.
- exp — already expired, or how long is left.
- nbf — not valid before a time; a future value is flagged.
- iat — issue time; a future value is a clock problem worth noticing.
- jti — an identifier used for replay protection.
Custom claims are shown too, decoded exactly as they appear. Nothing is renamed or dropped, so what you read is what the issuer put there.
Common JWT mistakes this page surfaces
- An unsigned token (
alg: none) that looks like a signed one. - No
expat all, so the token never expires on its own. - A token past its expiry that a client keeps sending.
- A five-segment JWE treated as a JWT and pasted into the wrong tool.