JWT Decoder

A JSON Web Token (JWT) is a compact string used to carry identity and permission claims between systems, typically after you sign in. It has three dot-separated parts: a header, a payload and a signature. This decoder reads the first two so you can see what a token contains and when it expires.

Decoding is done entirely in your browser and the token is not uploaded. This tool does not verify signatures, and it should not be used to decide whether a token can be trusted.

A JWT looks like xxxxx.yyyyy.zzzzz. The first part is the header, a small JSON object that names the signing algorithm (such as HS256 or RS256) and the token type. The second is the payload, a JSON object of claims. The third is the signature, which lets a server confirm that the header and payload were not altered. Each part is encoded with Base64URL, which is why you can read the first two without any key.

JWTs are defined by RFC 7519. Because the content is only encoded and not encrypted (unless it is a separate encrypted token type), anything in the payload is visible to anyone who holds the token. Never put secrets or sensitive personal data in a JWT payload.

The standard defines several common claims. iss (issuer) says who created the token; sub (subject) identifies the user or entity it is about; aud (audience) names the recipient it is meant for; exp (expiration time) is when it stops being valid; nbf (not before) is when it starts being valid; iat (issued at) is when it was created; and jti is a unique token identifier. The time claims are Unix timestamps in seconds, which this tool converts into readable UTC times and compares with your current time.

Applications also add their own claims, such as roles, scopes, tenant IDs or email addresses. Those appear in the payload JSON exactly as issued.

Reading a token and trusting it are very different. A forged token can look perfectly normal when decoded. To trust a JWT, a server must verify the signature with the correct key, check that the algorithm is one it expects, and validate exp, nbf, iss and aud. Known attacks include accepting the “none” algorithm or confusing symmetric and asymmetric algorithms, which is why verification belongs in well-tested libraries on the server and never in client-side inspection tools.

Treat real tokens as credentials. Although this tool processes the token locally, a live access token pasted into any web page could be exposed through browser extensions, screen sharing or clipboard managers. When possible, use expired or test tokens for debugging.