JWT decoded vs verified

What decoding does

A JSON Web Token usually has three dot-separated parts: a header, a payload, and a signature. The header and payload are JSON represented with Base64url. Decoding reverses that representation so a person can read the fields. It does not require a key because the encoding is meant to be reversible.

The payload can include an issuer, subject, audience, scopes, roles, and timestamps. It can also include arbitrary application claims. None of those names make a claim true. A user can create a token-shaped string with any payload and send it to an endpoint that does not verify it. A readable token is therefore an input to security analysis, not a security decision.

TheDevTab's JWT Decoder splits and decodes the parts in your browser. It shows the header and payload and keeps the signature as opaque text. If you paste a secret or public key, it can check that key against the original signature on your device. It does not re-sign the token, contact an issuer, or call a verification service.

What verification proves

Verification checks a signature with a key and the algorithm expected by the application. The exact process depends on the signing method and key type. A successful check can establish that the signed bytes were produced with the corresponding key and were not changed after signing. It does not automatically grant access or prove that every claim is appropriate.

A server should also check the allowed algorithm, issuer, audience, expiration, not-before time, and any application-specific authorization rule. It should obtain trusted keys through the identity system's documented mechanism and handle key rotation. Never accept an algorithm named by an untrusted token without comparing it with the server's policy.

alg: none is a useful warning because it describes a token with no signature. Anyone can change its claims. A different algorithm name is not proof of a valid signature either. The decoder can point out what the token says, while the service that accepts the token must enforce what it trusts.

Read exp, nbf, and iat carefully

The standard time claims are normally Unix seconds. exp is the time after which the token should not be accepted. nbf is the time before which it should not be accepted. iat is the time at which it was issued. A decoder can show the raw number and a UTC interpretation, but the application still chooses its clock-skew policy.

A missing expiration may be acceptable for one internal use and a serious policy error for another. A future issued-at time may indicate clock drift or a malformed fixture. A numeric value that is actually milliseconds can appear far outside the expected date. Check the token contract rather than accepting a badge as a verdict. Use theUnix Timestamp tool to inspect an isolated value when needed.

Handle tokens as secrets

A signed JWT is usually readable by anyone who obtains it. It may contain personal data, internal identifiers, or enough authority to call an API until it expires. Do not paste a production token into a ticket, screenshot, chat, or shared document. A browser-only decoder avoids uploading the token, but it cannot prevent someone standing behind you from seeing the screen or another local process from reading the clipboard.

For a reproduction, make a fixture with fake identifiers, a short lifetime, and a key that is not used anywhere. Then verify the fixture in the same library and configuration used by the service. Use JSON Formatter to inspect a copied payload after redaction, not as a replacement for a verifier.

Keep the boundary explicit

The useful mental model is simple: decoding answers "what bytes and claims are present?"; verification answers "was this signed by an accepted key, and do the claims pass policy?" Authorization answers a third question: "is this principal allowed to perform this action?" Mixing those steps is how an inspection tool becomes a security mistake.

When you need a local inspection of a sample token, use theJWT Decoder to read claims and, if you have a key, check the original signature in the browser. Keep the output untrusted until the application that receives the token has performed its own checks.