JWT decoder that explains the claims

No, and that is deliberate. Verifying needs the issuer's secret for HS256 or its public key for RS256 and ES256, and a web page that asks you to paste a signing secret next to a live token is asking for the one value that should never leave your own infrastructure. Verify where the key already lives instead — jose or jsonwebtoken in Node, PyJWT in Python, golang-jwt in Go — and pin the algorithm there rather than reading it out of the token.

Decoding only proves the token is well-formed; six further checks stand between that and acceptance. Roughly in order of how often they fire: exp has passed, aud does not contain the verifier's own identifier, iss is not the issuer it expects, the alg in the header is not the algorithm it pinned, kid names a key that has rotated out of the JWKS, and the signature does not match because the token came from a different environment. A NumericDate sent as a JSON string rather than a number is the seventh, and this page flags that one for you.

It means the token carries no signature at all. RFC 7519 §6 defines an unsecured JWS whose third segment is empty, meant for tokens already protected some other way — wrapped in a JWE, or carried over mutual TLS. It became notorious in 2015, when several libraries would verify an alg: none token against a configured key and return success, so an attacker could take a genuine token, rewrite the payload, drop the signature and be admitted as anyone. The fix is on the verifier: accept a fixed list of algorithms decided in your own code, never the one the header asks for.

On this page the token stays in your tab, split and decoded by JavaScript that was already downloaded, with nothing sent anywhere and nothing kept after you close it. That is not true of every decoder, and a JWT is a bearer credential: whoever holds it is the user until it expires. Check where the decoding happens before you paste, and treat a token you have pasted into a tool you do not control as spent — revoke it or let it expire rather than assuming nobody kept a copy.

No — editing the payload breaks the signature, and only the issuer can produce a new one. The third segment is an HMAC or a digital signature computed over the first two, so a single altered character in the payload gives a token that fails verification everywhere it is checked. To test a different set of claims, mint a fresh token from your own issuer or from a local key, which is a two-line script in any JWT library.

exp is a NumericDate — seconds, not milliseconds, since 1970-01-01 UTC — after which the token must be rejected. 2051222400 works out to 2035-01-01T00:00:00Z, which this page shows beside the raw number along with the same instant in your own time zone. The classic bug is passing Date.now() straight into the claim: that is milliseconds, so the token expires roughly 56,000 years from now, and any date claim above 100,000,000,000 gets flagged here for exactly that reason. Verifiers typically allow about 60 seconds of clock skew either side.

Five segments means a JWE, an encrypted token rather than a signed one. The parts are the protected header, an encrypted content key, an initialisation vector, the ciphertext and an authentication tag, and only that first header is readable without the decryption key. No browser tool can show you the claims inside one; you have to decrypt it where the private key lives. This page recognises the shape and says so rather than printing nonsense.