JWT decoder

How a JWT is put together

A JSON Web Token in compact form is three base64url strings joined by dots:

header.payload.signature

• Header: JSON describing the token, most importantly alg, the signing algorithm.
• Payload: JSON claims such as the user id (sub), issuer (iss), audience (aud) and expiry (exp).
• Signature: computed over header.payload with a secret or private key.

The decoder reverses the base64url encoding of the first two parts and shows them as JSON. It also converts the time claims to readable dates and checks the token for common mistakes. It does not check the signature.

Example

The sample token decodes to this payload:

{
  "sub": "user_8421",
  "name": "Ada Lovelace",
  "roles": ["admin", "billing"],
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "iat": 1767225600,
  "nbf": 1767225600,
  "exp": 1767229200
}

iat and exp are one hour apart: issued 2026-01-01 00:00 UTC and expiring at 01:00 UTC. That is a sensible lifetime for an access token.

Decoding a token on the command line

You don’t need a website to read a payload. With jq installed:

cut -d. -f2 <<<"$TOKEN" | tr '_-' '/+' | base64 -d 2>/dev/null | jq .

base64 -d may complain about missing padding. The JSON usually prints anyway; add = characters until the length is a multiple of four if it does not.

What the warnings mean

Validating tokens in your own code

Decoding is not validation. A server should, in this order:

1. Reject tokens whose alg is not the one it expects. Never take it from the header.
2. Verify the signature with the right key (look up kid in your JWKS).
3. Check exp and nbf, allowing a small clock skew of 30–60 seconds.
4. Check iss and aud match your issuer and your service.

Most libraries do all of this when configured with an explicit algorithm, issuer and audience. Do that instead of decoding claims yourself.