A Readable JWT Is Not a Verified JWT

A decoder can turn a long string into tidy fields. That is useful for debugging, but it can make untrusted information look more authoritative than it is. The illustration is an original concept graphic, not a real token or verification result. Three different questions RFC 7519 describes JWTs that can be signed, integrity-protected, or encrypted. A common signed form has three dot-separated parts. Its header and claims are encoded, not concealed by that encoding. Question / What answers it What does this token say? / Decoding its readable fields. Is its cryptographic protection valid? / Verification with the expected key and permitted algorithm. Should this application accept it? / Validation against the application's issuer, audience, time, and token-type requirements. Those questions are not interchangeable. An encrypted token also needs the appropriate decryption process; a text decoder is not a decryption service. Treat the fields as assertions In the standard, iss identifies an issuer, aud an intended audience, and exp an expiration time. The expiry uses a time value measured in seconds from the Unix epoch, not JavaScript's usual milliseconds. Which claims an application requires depends on its token profile. A displayed name, role, or future expiry is not independent evidence. Do not grant access because decoded JSON contains an administrator flag, and do not describe a token as valid merely because its displayed time has not passed. RFC 8725 calls for an application-controlled algorithm allowlist and verification of the relevant cryptographic operations. It also addresses trusted issuers, intended audiences, and confusion between tokens issued for different purposes. The server should apply its established validation rules through an appropriate library, not trust instructions supplied by the token itself. Inspect an example, not a live credential Our JWT decoder reads headers and claims locally; it does not verify a signature. For learning or a bug report, use a disposable example that cannot access a real account. Share the field names and the observed problem rather than the complete credential. The bearer-token specification explains the disclosure risk: possession can be enough to use the associated authorization. Not every JWT is a bearer access token, but the file format alone is no reason to treat one casually. Before sending a screenshot, check both the input and decoded output for tokens, account identifiers, and personal information. Local decoding does not make an unredacted screenshot safe to publish. When a token has already been exposed Treat a live credential as an incident to resolve through the issuing service. Follow that service's revocation or session-reset procedure and check which credentials were affected. Do not assume that deleting a message or changing a displayed JSON field invalidates the original token. Use the privacy resources for other checks. Keep the conclusion narrow: a decoder tells you what it read, not whether someone should trust it.