Reading a JWT: visible claims are not verified claims
While developing an integration, you may need to inspect a JWT’s fields. Reading them helps diagnosis; it does not make their contents established facts or permission to act.
What can inspection reveal?
A three-part compact form can expose a readable encoded header and payload. These may include an algorithm name and claims about a subject, intended audience and expiration.
The current tool displays this structure locally; it does not decrypt JWE tokens. A readable payload also means placing information in it does not conceal it from whoever holds the token.
References: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
Decoding does not authenticate the issuer
A trust decision requires cryptographic verification and the expected application context. An algorithm name in the header or a permission in the payload does not prove the right issuer supplied it.
Here verified remains false: signatures, issuer identity, expiry and authorization are not checked. Use the application’s approved verification mechanism for access decisions, not the decoder’s displayed text.
References: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
Interpret time carefully and handle tokens discreetly
The standard exp value is seconds from the Unix epoch, not milliseconds or a local calendar date. Reading that date does not mean the decoder checked it against the current clock.
Avoid placing real tokens in chats, support documents or public screenshots. Learn with synthetic data, and do not treat successful decoding after an edit as evidence that the edited token will be accepted.
References: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
A diagnostic example that grants no permission
A synthetic payload {"sub":"example-reader","exp":1893456000} describes an exp instant of 2030-01-01T00:00:00Z. That interprets a field; it does not establish that a trusted system issued the token.
A readable payload may decode even when the signature portion is cryptographically invalid; this decoder still returns verified=false. Editing sub or exp does not authorize the new token, and a long-looking signature cannot be verified by eye.