JWT Decoder

A decoded token is not a verified token

The first two segments are base64url-encoded JSON — not encrypted, not signed in any way you can read. Anyone can decode them and anyone can write new ones. Trust comes from the third segment, and checking it needs the key: the shared secret for HS256, or the issuer's public key for RS256 and ES256. This page has neither and cannot have either.

So what you read is what the token claims about itself, and a forged token decodes as cleanly as a real one. The honest use of this page is debugging: which claims your issuer emits, and why the consumer rejected them.

Read the header suspiciously

• alg lets the token influence how it is checked. An odd design decision in hindsight. alg: none is legal in the specification and produces an empty signature — a library that honours it accepts anything. If a token you are debugging has an unexpected alg, that is the finding.
• Algorithm confusion is the classic attack. A token issued as RS256 is resubmitted as HS256, and the verifier obligingly uses the public key as an HMAC secret — which the attacker already has.
• A stale kid is the top cause after expiry. It names which key to use when the issuer publishes several. A token that decodes fine but fails to verify usually points at a key that rotated while the consumer cached the old set.

Expiry here is measured against your clock

• Time claims are NumericDate — seconds, not milliseconds. That is why a token pasted into a tool assuming milliseconds appears to expire in 1970.
• Skew explains a token valid here and refused there. This verdict uses the clock of the machine you are sitting at; the verifier used its clock. A few minutes is enough, which is why most libraries allow leeway.
• Three other claims decide acceptance. nbf rejects a token issued slightly in the future; aud is how a token minted for one API is refused by another; and iss. So "Expires in 30d" is not a prediction that anything will accept it.
• A perfectly valid token can still be dead. Logout and forced sign-out are enforced in the issuer's revocation or session list. Nothing inside a JWT can tell you it has been revoked.

When to use something else

For the design questions behind the token — lifetime, what belongs in a claim and what has to be looked up, where the policy decision point sits — zero-trust-architecture covers it in NIST SP 800-207 terms. A bearer token is only as confidential as its channel, so for the transport see the tls-configuration-review prompt. To chase a token that appeared where it should not have, secrets-scanner finds the ones committed to a repository.

The splitting, the base64url translation and the JSON parsing all run as JavaScript in this tab, with no API call and no server round trip — the only acceptable arrangement, because a JWT is a live credential and pasting a production one into a site that posts it anywhere hands over the session. Treat any token you paste into any online decoder as compromised, including this one: you cannot verify from the outside what a page does.