JWT Decoder

A JSON Web Token, or JWT, is a compact way to carry claims between systems. It is commonly used in authentication and authorization flows, but the format itself is simply a structured token. A typical JWT has three Base64URL-encoded parts separated by dots: a header, a payload, and a signature.

The header describes the token type and signing algorithm. The payload contains claims such as subject, issuer, audience, expiration time, roles, or application-specific data. The signature is used to detect tampering when the verifier has the correct secret or public key. The token is portable because it can travel in HTTP headers, cookies, or other text-based channels.

JWT headers and payloads are encoded, not encrypted, unless a separate encrypted token format is used. Anyone who has the token can decode those sections and read the claims. That is why sensitive secrets do not belong in ordinary JWT payloads.

Verification is a different step. A system must check the signature, algorithm, issuer, audience, expiration, not-before time, and any application-specific constraints before trusting the token. A decoded token can be useful for debugging, but it should never be treated as valid merely because it parses cleanly. Security comes from verification and policy checks, not from the visual structure of the token.

Registered claims provide common vocabulary. The iss claim names the issuer, sub identifies the subject, aud names the intended audience, exp gives expiration, and nbf can prevent use before a certain time. Private claims add application-specific meaning, such as tenant identifiers or permission scopes.

Token lifetime is a major design choice. Short-lived tokens reduce risk if stolen, but they require refresh flows or more frequent reauthentication. Long-lived tokens improve convenience but increase exposure. Many systems pair short-lived access tokens with carefully controlled refresh tokens, plus revocation strategies for account changes and incident response.

JWT problems often come from key handling, algorithm confusion, clock skew, oversized payloads, or inconsistent validation across services. A service that checks expiration but ignores audience may accept a token meant for another system. A service that trusts a user-controlled algorithm field can be vulnerable if libraries are misused.

Good JWT practice is boring in the best way: keep payloads minimal, use well-supported algorithms, rotate keys deliberately, validate every relevant claim, and log enough metadata to debug failures without exposing full tokens. The format is convenient, but convenience does not replace careful trust boundaries.