What is JWT and how to decode it

A JWT usually has three dot-separated sections: header, payload, and signature. The header describes metadata such as the algorithm and token type. The payload contains claims such as subject, issuer, audience, expiration, roles, or custom application data. The signature is used by the receiving system to verify that the token was issued by a trusted party and has not been changed.

The first two sections are Base64URL-encoded JSON. That means they are easy to decode into readable text. Encoding is not encryption. Anyone who has the token can usually read the header and payload.

Decoding turns the header and payload back into JSON so humans can inspect them. Developers decode JWTs when debugging authentication, checking scopes, investigating expiration, or confirming which user identifier appears in the token.

A decoder is useful for visibility, but it does not say whether the token should be accepted by an API. A malicious user can create a token with any payload. Without signature verification, those claims are just text.

Verification checks the signature using the correct secret or public key. It also checks claims such as issuer, audience, expiration, not-before time, and sometimes authorized party or scope. This work belongs in backend or trusted application code.

If verification fails, the decoded payload should not be trusted. If verification succeeds, the application can use claims according to its authorization rules.

When debugging JWTs, avoid pasting live access tokens into public chats, screenshots, or tickets. Tokens may include user identifiers or grant access to APIs. If you need help, redact the signature and sensitive claims or use a test token.

Use a decoder to inspect structure, then use your application logs or backend verification flow to confirm trust. Decoding and verification answer different questions.