JWT Decoder

Does decoding a token prove it is genuine?

No. Anyone can build a token with any payload, so a decoded payload says only what the token claims. Proof comes from checking the signature against the issuer’s secret or public key, and this tool does not do that. Every result ends with the note that the signature is not verified. Use the output to debug and inspect, never to decide whether to trust a token.

Why does a token with "alg": "none" decode without complaint?

Because decoding does not look at the signature. A token whose header says none and whose third part is empty is displayed like any other, with an empty Signature row. A server accepting such a token would be accepting unsigned data, so treat the none algorithm shown in the Algorithm row as a warning sign when you meet it in something that is supposed to be protected.

What does the EXPIRED or NOT YET VALID label mean?

It compares the exp or nbf claim with the clock of the device you are using. EXPIRED is added when exp is in the past, and NOT YET VALID when nbf is in the future. There is no allowance for clock differences between servers, which real validators often add, and a wrong device clock gives wrong labels.

The expiry shows a date in the year 55840. What happened?

The exp claim is probably in milliseconds. JWT time claims are defined as seconds since 1970, so a 13-digit value is multiplied by 1000 again and lands tens of thousands of years ahead. A token issued by a library that wrote milliseconds is a bug in the issuer, and this display is a quick way to spot it. For example, exp 1700003600000 shows Sun, 20 Dec 55840.

Why do I get "Failed to decode token"?

One of the first two parts is not valid Base64URL text holding a JSON object. Common causes are a truncated copy, a stray character in the middle, or a token that is not a signed JWT at all. A leading "Bearer " or "Authorization:" prefix and surrounding quotes are stripped for you. Tokens with five parts are encrypted JWTs (JWE); the tool reports "got 5" for those because their contents cannot be read without the key.

Are non-English characters in claims displayed correctly?

Yes. The decoded bytes are read as UTF-8, so a name claim of "Zoë Müller" displays as written rather than as garbled letters. Claims that contain escape sequences are shown after JSON parsing and are therefore already unescaped.

Which claims get their own row?

iat, nbf, exp, sub and iss, when present, plus the algorithm and type from the header. Everything else, including aud, jti, scopes, roles and custom claims, is visible in the full Payload (decoded) block but has no separate row. Time claims are shown as UTC dates; the raw numbers stay in the payload block.

Can I paste a token from production?

Tokens often carry user IDs, email addresses and roles, and a live access token can be used by anyone who has it until it expires. Prefer expired or test tokens, or remove the signature part before pasting: the header and payload decode without it, although the tool wants three dot-separated parts, so keep the final dot.