JWT decoding is not JWT verification

Why every JWT is easy to read

A common compact JWT contains three dot-separated sections: a header, a payload, and a signature. The first two sections are JSON encoded with Base64URL so they can travel in text protocols. Base64URL is reversible without a key, which means anyone who receives the token can normally read its algorithm label and claims.

That readability is intentional. A JWT is often signed rather than encrypted. The signature protects integrity and origin when it is verified correctly, but it does not hide the payload. Passwords, private keys, regulated identifiers, and other secrets generally do not belong in readable claims merely because the token string looks opaque.

What a decoder can and cannot tell you

A decoder can reveal fields such as issuer, subject, audience, scopes, expiration, and not-before time. This is useful for diagnosing the wrong tenant, environment, role, or clock value. It can also report malformed Base64URL or invalid JSON. None of those observations prove that the issuer created the token.

An attacker can create a header and payload with any claims they want. If an application makes an authorization decision from decoded claims before verifying the signature, the claims are simply user-controlled input. A successful decode therefore means only that the first two sections follow an expected representation.

Verification requires application context

Real verification uses a trusted key and an expected algorithm. The verifier must reject unexpected algorithms rather than accepting whatever the token header requests. For asymmetric signatures it may retrieve a key set from a trusted issuer, select the correct key, and enforce rotation and caching rules.

Signature verification is still not the final authorization check. The application should validate issuer, audience, expiration, not-before time, token type, required scopes, and any tenant or session policy. Some systems also maintain revocation or account-state checks that cannot be represented by the token alone.

• Pin accepted algorithms in application configuration.
• Match issuer and audience exactly.
• Allow only a deliberate amount of clock skew.
• Treat unknown critical headers and claim types as errors.

Use real tokens with care

Bearer tokens can grant access to data or actions until they expire or are revoked. Prefer an expired, test, or redacted token when investigating structure. Even with local decoding, other software on the device can access the clipboard or observe the screen.

If a production token is posted in a ticket, chat, recording, or public issue, assume it is compromised. Remove the disclosure where possible, revoke or rotate the token, and review access logs. Deleting the visible message does not guarantee that every copy disappeared.