JWT Decoder

What is inside a JSON Web Token

A JWT (RFC 7519) is a signed statement that some issuer makes about some subject, encoded so it survives a URL or an HTTP header. The three dot-separated parts each do one job.

• The header names the algorithm and the type: {"alg":"HS256","typ":"JWT"}. It may also carry kid, the key id, which tells the verifier which of several public keys to check against.
• The payload the claims. Registered ones have agreed meanings: iss (issuer), sub (subject, usually the user id), aud (audience), exp (expiry), iat (issued at), nbf (not before), jti (a unique id). Everything else is whatever the issuer chose to put there: roles, a tenant, an email.
• The signature the first two parts signed with the key. It is what makes the token trustworthy, and it is the one part this tool deliberately does not touch.

Decoding is not verifying

This is the distinction that matters, and the one that causes real security incidents. Decoding a JWT reads it. Verifying a JWT proves that the issuer actually signed it and that nobody changed a claim on the way. They are different operations, and only the second one makes the contents trustworthy.

Anyone holding a token can decode it: that is what you are doing on this page. So a JWT payload is not a place to put anything you would not want read: it is signed, not encrypted. If the claims need to be unreadable to the bearer, you want JWE, or an opaque token whose meaning lives only in your own database.

And never let an unverified token decide anything. The classic attack is the "alg": "none" token, where an attacker strips the signature and rewrites the claims; a server that decodes without verifying accepts it as an administrator. A library that verifies should be told which algorithms it may accept, rather than trusting the header to pick.

Answering the questions you actually came with

• "Is this token expired?" exp is shown as a date and compared against your clock. Remember the clock is yours: a few seconds of skew between your machine and the server is normal, and most libraries allow a small leeway for exactly this reason.
• "Which account is this?" sub is the subject, the stable identifier. The display name beside it, if there is one, is a convenience and can change; sub should not.
• "Why is the gateway rejecting it?" check aud against what the API expects, iss against the issuer it trusts, and nbf, which makes a token invalid until a moment that may not have arrived yet.
• "Which key signed it?" the kid in the header, matched against the keys published at the issuer’s JWKS endpoint. A rotated key with a stale cache is a common cause of sudden mass rejection.

When a token will not decode

• It is not three parts count the dots: a JWT has exactly two. One dot usually means the signature was trimmed; four means two tokens were pasted together.
• A character outside the Base64 alphabet almost always a truncated copy that picked up a quote, a comma or a trailing ellipsis from the surrounding text. Check both ends of the string first.
• It decodes but is not JSON then it is probably not a JWT at all. Opaque session tokens and API keys are often Base64 too, and carry no readable structure: their meaning lives in the issuer’s database.
• A Bearer prefix copied straight from an Authorization header. It is stripped here automatically, but a library that is handed the whole header value will not do that for you.