How It Works

A JWT (JSON Web Token) in its signed form (JWS) has three parts: header, payload, and signature. The three parts are separated by dots (.) and encoded with base64url.

This tool splits the token into its parts, shows the header and payload as JSON, and leaves the signature in its raw form.

Important warning

This tool does not verify the signature. The fact that a token “can be decoded” does not mean it is valid. In production, always:

Verify the signature on the server side (the shared secret for HS256, the public key for RS256).
Check the exp (expiration) and nbf (not-before) claims.
Compare the iss and aud claims against the values you expect.

Trusting the payload without these checks is no different from skipping authentication entirely.

Common claims

iss — who issued the token (issuer).
sub — the subject the token refers to, usually a user ID.
aud — the party the token was issued for (audience).
exp — expiration time (Unix timestamp).
iat — when it was issued (Unix timestamp).
nbf — the earliest time it becomes usable.
jti — a unique token ID — for detecting replay attacks.

JWS vs JWE

This tool works only with JWS (signed but not encrypted) tokens. A JWE (encrypted) token splits into five parts, not three, so the tool rejects it at the part-count check before it ever reaches the payload.

Privacy

The token you paste is processed entirely in your browser. Even so, I’d recommend not pasting your production tokens — a token is a risk for as long as it sits anywhere it can leak from (history, clipboard, screen sharing).