JWT Decode explained

A JSON Web Token usually has three dot-separated parts: header, payload, and signature. The header describes the token type and signing algorithm. The payload contains claims such as subject, issuer, audience, expiration time, scopes, roles, or application-specific fields. The signature helps the receiving system verify that the token was signed by a trusted party.

The header and payload are Base64URL encoded JSON. That means they can be decoded into readable JSON without a secret key. This surprises many developers at first. Decoding a JWT is normal and useful, but it does not prove the token is valid. Validation requires checking the signature and claims against the rules of the application.

JWT decoding is useful when debugging authentication and authorization problems. If an API returns 401 or 403, the token may be expired, issued for the wrong audience, missing a required scope, or generated by the wrong issuer. Decoding the payload makes those values visible so you can compare them with the backend expectation.

It also helps during integration testing. A frontend may receive a token from an identity provider, pass it to an API, and fail because a claim name changed. Decoding the token shows the exact claim set without needing to add temporary server logs or inspect identity provider dashboards for every request.

The exp claim is the expiration time, usually stored as a Unix timestamp. The iat claim is issued at. The nbf claim means not before. The iss claim identifies the issuer, aud identifies the audience, and sub identifies the subject. Applications may also include scopes, roles, tenant IDs, organization IDs, or feature flags.

When debugging, compare these claims with the service that rejects the token. An audience mismatch is common when tokens are sent to the wrong API. Expired tokens are common in local testing. Missing scopes are common when a login flow requests insufficient permissions or when the identity provider changed its configuration.

A decoded JWT should be treated as untrusted text until the signature is verified. Anyone can create a token-shaped string with a plausible payload. If a tool only decodes the token, it is showing what the token claims, not proving that the claims are true. Backend services must verify the signature, issuer, audience, time claims, and any application rules.

This distinction matters in security reviews. It is fine to decode a token in the browser for debugging. It is not fine to make authorization decisions based only on decoded frontend data. The server must be the source of enforcement because it can validate the token against trusted keys and configuration.

Paste the token into a JWT decoder, inspect the header and payload, then format the JSON for readability. Check exp first if the failure is intermittent. Check aud and iss if the token came from a different environment. Check scopes or roles if authentication succeeds but a specific action is forbidden.

Remove real tokens from screenshots, tickets, and public examples. Even if a token is expired, it may contain user identifiers or internal claims. For documentation, create a synthetic token or redact sensitive values while preserving the shape that explains the issue.

Do not paste active production tokens into public tools, public issue trackers, or screenshots. A JWT can contain personal data, tenant identifiers, roles, scopes, and sometimes enough information to help an attacker understand your authorization model. If you need to discuss a token, redact the signature and sensitive claims or create a synthetic token with the same claim names.

Do not fix authorization problems only by changing frontend checks. Frontend decoding is useful for display and debugging, but enforcement belongs on the server. The backend should verify the signature, issuer, audience, expiry, and permissions every time a protected operation is requested. A decoded token in the browser is evidence to inspect, not an authorization decision.

When an issue depends on time, convert exp, iat, and nbf claims into a readable timestamp and include the timezone in your notes. Many token bugs come from clock skew, staging environments with different lifetimes, or cached tokens that outlive a role change. Clear timestamps make those problems much easier to discuss across frontend, backend, and identity teams.

If the token came from a staging identity provider, mention the environment too. A valid staging token should usually fail against production services.