JWT Decoder

About JWT Decoder

A JWT decoder reveals the header and payload of a JSON Web Token without needing the signing secret. Paste a token and it splits and Base64URL-decodes the segments to show the algorithm, claims, and any expiry (exp, iat, nbf) as readable dates. Decoding happens entirely in your browser, so your token is never sent to a server and stays private.

Encoded is not encrypted

A standard JWT has three dot-separated parts: header, payload, and signature. The first two are Base64URL-encoded, not encrypted. Anyone holding the token can read every claim inside it without any secret at all — which is exactly what this decoder does. Encoding here exists to make the data safe to put in a URL or header, not to hide it.

The practical rule follows directly: never put anything in a JWT payload that the bearer should not see. No passwords, no internal notes, no personal data beyond what the client already knows about itself. The signature guarantees the claims have not been altered; it does nothing to keep them private.

The claims that control validity

Three registered claims are timestamps, all in Unix seconds. exp is the expiry, after which the token must be rejected. iat is when it was issued. nbf means not before — a token that is valid but not yet active. A decoder that renders these as readable dates saves a lot of confusion, because a ten-digit integer tells you nothing at a glance.

The others matter for security. iss names the issuer and aud names the intended audience; a correct verifier checks both, because a perfectly valid token issued for a different service should not be accepted by yours. sub identifies the subject, usually a user id. jti is a unique token id, which is what makes selective revocation possible.

The alg none attack, and why algorithm matters

The header names the signing algorithm, and historically that was a serious flaw. If a verifier trusts the header's alg field to decide how to verify, an attacker can set it to none, strip the signature, and forge any claims they like. Libraries have largely fixed this, but the underlying lesson stands: the server must decide which algorithm it accepts, and reject tokens that arrive claiming anything else.

A related confusion attack swaps RS256 for HS256. RS256 verifies with a public key; HS256 verifies with a shared secret. If the server naively uses the public key as an HMAC secret, an attacker who knows the public key — which is public by definition — can sign their own tokens. Pin the expected algorithm explicitly rather than reading it from the token.

Debugging a rejected token

When a token is refused, decode it before assuming the signature is wrong. The most common cause by far is expiry, and the second most common is clock skew between the issuing and verifying machines — a token issued a second in the future fails an nbf or iat check on a server whose clock lags. A few seconds of allowed leeway solves it.

After that, check aud and iss against what the verifier expects, since a copied configuration often points at the wrong environment. If those are right and it still fails, the signature genuinely does not match: usually the wrong key, a key rotated since issuance, or whitespace or a line break introduced when the token was copied and pasted.

Frequently asked questions

Does decoding a JWT verify the signature?

No. Decoding only reads the header and payload — it does not verify the signature. Anyone can decode a JWT without a key, so never trust a token's claims until you've verified it server-side with the signing secret or public key.

Is a JWT encrypted, or can anyone read it?

A standard JWT is only Base64URL-encoded, not encrypted, so anyone can decode and read its header and payload. Never put secrets in a JWT payload.

Can I see when a token expires?

Yes. Standard time claims — exp (expires), iat (issued at), and nbf (not before) — are shown as human-readable dates so you can check a token's validity at a glance.

Is my token uploaded to a server?

No. The token is decoded locally in your browser and never sent anywhere.