JWT Decoder & Inspector

Three parts, separated by dots

The header names the signing algorithm. The payload holds the claims. The signature is computed over the first two parts together with a secret or a private key. Only the signature is genuinely opaque: the other two are ordinary JSON that anyone can read, which is what the tool above does.

eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiI0MiJ9 . 3rXNPl7ZgqLm...
|__________________|   |______________|   |____________|
       header               payload          signature

header   {"alg":"HS256","typ":"JWT"}
payload  {"sub":"42","exp":1893456000}

The payload is encoded, not encrypted

This is the thing to internalise. base64url is not a cipher: it has no key and reversing it is a single function call. Every claim in a token is readable by the browser it was sent to, by every proxy it passes through, and by anything that logged the request. Putting a password, an API key or a national ID number in a payload is publishing it. If a token has ever contained one, treat that value as leaked and rotate it.

The signature proves integrity, not secrecy

A signature answers one question: has this token been altered since it was issued? It says nothing about whether the contents are private, because they are not. Verifying means recomputing the signature with the issuer's key and comparing, which is why verification belongs on your server, and why this page decodes but deliberately does not verify.

signature = HMAC-SHA256(
    base64url(header) + "." + base64url(payload),
    secret
)

change one character of the payload and the signature no longer matches

The claims that carry the security

Seven claim names are registered in RFC 7519 and the rest are yours. Three of them are timestamps, given as NumericDate: seconds since the Unix epoch, as a JSON number. Emitting those in milliseconds is a common bug and pushes the expiry into the year 55000, which reads as 'never expires' to anything checking it.

iss   issuer            who minted it
sub   subject           who it is about, usually the user id
aud   audience          which service is allowed to accept it
exp   expires at        seconds since 1970, NOT milliseconds
nbf   not valid before  seconds since 1970
iat   issued at         seconds since 1970
jti   token id          unique, for replay detection or a denylist

Why you cannot revoke one

The reason a JWT scales is that the verifier never has to ask anyone whether it is still valid: the signature and the expiry are enough. That is also why logging someone out does not invalidate their token. Once issued, it is accepted until it expires, so the gap between iat and exp is the real blast radius of a leak. Short-lived access tokens with a refresh token behind them is the standard answer; a denylist keyed on jti works but gives back the statelessness you chose a JWT for.

alg: none, and why verifiers pin the algorithm

The header names its own algorithm, which means an attacker gets to suggest how their token should be checked. Set alg to none, strip the signature, and a naive verifier that trusts the header will accept an edited payload. A related attack takes an RS256 public key, which is public, and submits a token signed HS256 using that key as the HMAC secret. Both are fixed the same way: decide server-side which algorithm you accept and refuse everything else.

# what a verifier should do
verify(token, key, algorithms=["RS256"])   # pinned

# what it should never do
verify(token, key)                          # trusts header.alg