A JSON Web Token is just three Base64 pieces
JWTs look intimidating, but their structure is simple: three URL-safe Base64 strings joined by dots. The first is the header (algorithm and token type), the second is the payload (the claims), and the third is the signature. Decoding the first two pieces is trivial — and that is exactly what this tool does, locally in your browser.
Decoding is not the same as verifying. A decoded JWT shows you what the token claims to be; verification requires checking the signature against the secret or public key. This tool does the safe, common operation of inspecting tokens during development without ever asking for your keys.
Registered claims explained
- iss — issuer. The party that created the token.
- sub — subject. Usually the user or principal the token represents.
- aud — audience. The intended recipient (often an API URL).
- exp — expiration. Unix timestamp after which the token is invalid.
- nbf — not before. The token is invalid before this timestamp.
- iat — issued at. The timestamp when the token was created.
- jti — JWT ID. A unique identifier for revocation lists.
When you would use it
During API development, when debugging a 401 response and you want to confirm what the token actually contains. During incident response, when an expired token is rejecting users and you need to read the exp claim. During security review, when checking which audiences and scopes a token grants. The tool is read-only and local — paste any token without worrying about leaking it.