Authentication guide

How to inspect a JWT without trusting it

Decoding is useful for debugging, but it is not authentication and it does not establish that a token is safe to accept.

What decoding actually proves

A JSON Web Token commonly contains three dot-separated segments: a protected header, a payload, and a signature. The first two segments use Base64URL encoding, which makes them readable without a secret. Opening a token in the JWT Decoder proves only that those segments can be decoded and parsed. Anyone can construct different header and payload text.

Use decoded claims to diagnose an integration: check the issuer (iss), intended audience (aud), subject (sub), expiry (exp), not-before time (nbf), scopes, and roles. Do not use the displayed values to authorize a request unless the application has completed cryptographic and policy validation.

The receiving application must verify the token

Verification should restrict accepted algorithms rather than trusting the token's alg value, select the correct verification key, validate the signature, require the expected issuer and audience, and enforce time claims with a deliberate clock-skew policy. Key rotation and token revocation behavior belong to the identity platform and application—not to a decoder.

An expiry value is normally a NumericDate measured in seconds from the Unix epoch. If a displayed date is implausibly far in the future or near 1970, confirm the units with the Unix Timestamp Converter.

Handle tokens as credentials

JWT payloads can reveal names, tenant identifiers, email addresses, internal roles, and infrastructure details. A bearer token may grant access until it expires. Avoid pasting production tokens into tickets, analytics tools, chat messages, or shared screenshots. Prefer a short-lived development token with fictional claims, and revoke or rotate any credential exposed outside its intended boundary.

Debugging checklist

1. Use a non-production token where possible.
2. Inspect the header algorithm and key identifier.
3. Compare issuer and audience with application configuration.
4. Convert time claims using seconds, not milliseconds.
5. Verify the signature and policy in the actual authentication library.

References

Token structure and claims are defined by RFC 7519. Security considerations are expanded in RFC 8725: JWT Best Current Practices.