JWT Decoder

A JWT (JSON Web Token) is a compact, URL-safe token format used for authentication and information exchange between services. A JWT has three Base64url-encoded parts separated by dots: the header (algorithm and token type), the payload (claims — user ID, roles, expiry), and the signature. This tool decodes the header and payload, shows expiry status, and clearly notes that the signature is not verified — because signature verification requires the secret key.

What the claims mean

sub — subject (usually the user ID). iat — issued at (Unix timestamp). exp — expiry (Unix timestamp). aud — audience (the intended recipient service). iss — issuer (the authentication server). jti — JWT ID (unique identifier for this token, used for revocation). These are standard claims; applications add custom claims alongside them (roles, permissions, org IDs).

Using this tool safely

This tool runs entirely in your browser — pasting a JWT here does not expose it to any third party. That said, production JWTs from live systems contain real user identifiers and session data. If you are debugging a production system, prefer to copy the JWT into a local tool or this browser-only decoder rather than a server-side service. Treat long-lived JWTs (weeks or months of expiry) as secrets.

Remember: decoding a JWT does not mean trusting it. Any client can craft a JWT payload with any claims — only the signature, verified with the correct key, proves the token is authentic. Always verify signatures on the server before trusting JWT claims.

A JSON Web Token is three base64url segments separated by dots: header.payload.signature. The header names the signing algorithm, the payload carries the claims, and the signature proves the first two have not been altered.

The critical point: the header and payload are encoded, not encrypted. Anyone holding the token can read every claim in it — no key required. That is what this decoder does, and it is why you must never put passwords, card numbers or other secrets in a JWT payload.

Decoding vs verifying

A decoded token tells you what it claims to be, never that the claim is true. Authorisation decisions must always come from server-side verification.

The claims worth checking

exp expiry and iat issued-at are Unix timestamps — our timestamp converter turns them into readable dates. iss names the issuer, aud the intended audience, and sub the subject, usually a user ID. An expired exp is the single most common cause of a token that “suddenly stopped working”.

Common failures

Beyond expiry: clock skew between servers rejecting a valid token, an aud mismatch when one service's token is sent to another, and algorithm confusion where a server is tricked into accepting alg: none or into treating an RSA public key as an HMAC secret. Always pin the expected algorithm rather than trusting the header.