JWT decoder

How is a JWT built?

A JWT has three parts with a dot between them: header.payload.signature. The first two are JSON encoded as base64url. Anyone can read them; they are not encrypted. So never put passwords or other secrets in a JWT. The signature only proves the content hasn't been changed.

Common claims

• sub: who the token is about (the user).
• iat: when the token was issued.
• exp: until when it is valid.
• nbf: from when it is valid.
• iss and aud: who issued it and who it is meant for.

The times are Unix timestamps, seconds since 1 January 1970. You can convert them yourself with the Unix timestamp converter.

Why a JWT decoder should run locally

A JWT is a credential. Whoever has a valid token can often act as that user until it expires, so pasting a production token into a website that sends it to a server is a real risk. This decoder reads the token in your browser and nothing leaves your device. Still, prefer test tokens, and treat a token you pasted in a shared place as leaked.

"Invalid token" or "expired": what to check

• Expired. Compare exp with the current time. A few minutes of clock difference between servers can make a fresh token look expired or not valid yet (nbf).
• Wrong audience or issuer. The aud and iss claims must match what your API expects.
• Not three parts. A JWT has two dots. Opaque tokens, such as OAuth access tokens from some providers, are random strings that cannot be decoded.

What decoding does not prove

Decoding only reads the content, and the example token is signed with the key secret. It does not prove the token is genuine; that needs a check of the signature with the right key, which your server does. Be suspicious of a token with "alg": "none": a correct server must reject it.

To see where the dates come from, use the Unix timestamp converter, and to read a single part by hand, use Base64 decode.