How to use it
- Paste your token into the input panel. Decoding starts immediately.
- Read the header, payload and signature in the output panel. Timestamp claims are rendered as dates.
- The status bar tells you whether the structure is valid, which algorithm the header declares, and how long until — or since — the token expires.
How JWT decoding works
A JSON Web Token is three Base64url-encoded segments joined by dots:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NSJ9.PsBHwHqQfLdEJUmmWr8xTn0zNBEeGRJHDfvW1oPfSSU
└──── header ────┘ └──── payload ────┘ └──────────── signature ────────────┘
The first segment is a JSON object describing how the token was signed — typically {"alg":"HS256","typ":"JWT"}. The second is the payload: the claims the issuer is asserting. Both are ordinary JSON that has been Base64url-encoded, which means decoding requires no key whatsoever. Any tool, in any language, can read them. This decoder does exactly that, locally.
The third segment is the only cryptographic part. It is a signature computed over the first two segments using the algorithm named in the header. With HS256 that means an HMAC with a shared secret; with RS256 it is an RSA signature verified with a public key. The signature proves two things: the token was produced by someone holding the key, and the header and payload have not been modified since. It proves nothing about confidentiality, because nothing here is encrypted.
Why this distinction matters in practice
Because the payload is readable by anyone who holds the token, a JWT is the wrong place for anything sensitive. Internal user IDs are fine; email addresses are borderline; API keys, permissions you would not want a user to see, or personal data are not. Tokens end up in browser storage, server logs, error trackers and support tickets — treat the payload as public.
The other classic mistake is trusting a decoded token. Decoding is not authentication. A server that reads the sub claim without verifying the signature will happily accept a token that an attacker edited by hand. Verification must happen, with the right key, before any claim is acted upon. Related to this is the alg: none attack: a token declaring no algorithm and carrying an empty signature must be rejected outright, not treated as valid.
Finally, expiry is a claim like any other. exp says when the issuer intended the token to stop being accepted, but only a server that checks it makes that real. This decoder compares exp and nbf against your device clock and flags the result — useful for the very common case where an API returns 401 and you want to know within seconds whether the token simply timed out.
Reading the claims
Some claim names are standardised (RFC 7519) and worth recognising on sight:
iss— issuer, who created the tokensub— subject, usually the user identifieraud— audience, which API is meant to accept itexp/nbf/iat— expires at, not before, issued at (Unix seconds)jti— a unique token ID, used to support revocation lists
Everything else is application-specific. Names like role, scope, permissions and tenant are conventions, not standards, so their meaning depends entirely on the system that issued the token.