Developer & Data

Read a JWT Payload Without Treating It as Verified

Updated

A decoded token can look convincing because its header and claims are readable. Readability is not authentication. Someone can change a payload and still produce text that decodes into a neat object.

JWT Decoder, Unverified displays the header and payload of a three part JWT. Its result explicitly says NOT VERIFIED.

What the three parts tell you

The first part carries the header, the second the payload and the third the signature bytes in the supported compact structure. The tool decodes the first two as JSON objects and reports the signature byte length.

A claim such as a role, issuer or expiry is only a value present in that unverified payload. The decoder does not establish that the issuer wrote it or that the signature matches an approved key.

Even an expiry that appears to be in the future is not a permission decision. A proper application must verify the signature and apply its own issuer, audience, time and authorisation checks.

Use demonstration tokens

A real bearer token may grant access to an account. Do not paste one into a public troubleshooting conversation merely because it looks like encoded text. The server receives the submitted token.

This tool does not verify algorithms or keys. It also does not decrypt the five part structure used by encrypted JWE tokens. Unsupported structures produce an error.

Decoding is useful for noticing a misspelled claim or understanding why an integration expects a particular field. It should remain separate from a production verification flow.

If a token fails in your application, compare a harmless sample against the application's documented validation requirements. A successful result in this decoder only means the supported parts could be read, not that the token is valid for signing in.

Reference: JWT specification and validation context.

Join the conversation

Your email address will not be published. Required fields are marked *

Explore Whatson tool information