How to Decode JWT Tokens and Understand Their Structure

If you work with web APIs, you have seen JWTs — those long strings with three dot-separated sections. They carry authentication claims, but they are encoded, not encrypted. Anyone can decode the payload. Here is how to inspect JWT tokens to debug auth issues, verify claims, and understand what your application is actually transmitting.

JWT structure: header, payload, signature

A JWT has three parts: the header (algorithm and token type), the payload (claims like user ID, roles, expiration), and the signature (which verifies the token has not been tampered with). The first two parts are Base64URL-encoded JSON. The ToolStand JWT Decoder splits the token, decodes each section, and displays the header and payload as formatted JSON. The signature section is shown but cannot be decoded without the secret key.

Key claims to check

exp (expiration). The Unix timestamp when the token expires. If it is in the past, the token is invalid. iat (issued at). When the token was created. sub (subject). The user ID or principal the token represents. iss (issuer). Who issued the token — should match your auth server. aud (audience). Who the token is intended for — should match your application.

Debugging with the decoder

When a user reports "I am logged in but getting 403 errors," paste their JWT into the decoder. Check the exp claim — if the token expired 5 minutes ago, that is your answer. Check the roles or permissions claim — maybe they do not have the required scope. The decoder turns a black-box token into readable data in seconds.

Security reminder

Decoding a JWT reveals its contents but does not verify its signature. Never trust a JWT payload unless you have verified the signature with the correct secret or public key. The decoder is a debugging tool, not a validation tool.

Explore all 109 free tools at toolstand.io. Free, forever. No sign-up. No download. Just tools that work.