Question 1

How do I decode a JWT token without a secret key?

Accepted Answer

You can decode the header and payload of any JWT (JSON Web Token) without needing the secret key or public key. JWTs consist of three Base64Url-encoded parts separated by dots: header.payload.signature. The header and payload are simply Base64Url-encoded JSON — they are not encrypted, only encoded. Any Base64Url decoder can reveal their contents. This is by design: JWTs are meant to be readable by the client so it can inspect claims like the token's expiration time (exp), issuer (iss), and subject (sub). Only the signature part requires the secret key — it verifies that the token hasn't been tampered with, but it doesn't hide the payload. jslet's JWT Decoder automatically splits the token at the dots, decodes each part from Base64Url, pretty-prints the JSON, converts epoch timestamps (iat, exp, nbf) to human-readable dates, and flags expired tokens with a red badge. Paste any JWT from your browser's localStorage or an API Authorization header to inspect its claims instantly.

Question 2

What are the three parts of a JWT — header, payload, and signature?

Accepted Answer

A JWT is structured as three Base64Url-encoded segments separated by periods: header.payload.signature. The header contains metadata about the token — which signing algorithm was used (e.g., HS256 for HMAC-SHA256 or RS256 for RSA-SHA256) and the token type (JWT). The payload contains the claims — key-value pairs that describe the authenticated entity. Standard registered claims include iss (issuer — who created the token), sub (subject — who the token is about), aud (audience — who the token is intended for), exp (expiration time as a Unix timestamp), iat (issued-at time), and nbf (not-before time). Custom private claims can carry any application-specific data like user roles, permissions, or tenant IDs. The signature is a cryptographic hash of the encoded header + "." + encoded payload, computed using the algorithm specified in the header and the server's secret key. It proves the token was issued by a trusted authority and hasn't been modified in transit. If anyone changes a single character in the payload, the signature won't match and the server rejects the token.

Question 3

How do I check if my JWT token has expired?

Accepted Answer

Your JWT's expiration is stored in the payload as the 'exp' claim — a Unix timestamp (seconds since January 1, 1970 UTC) indicating when the token becomes invalid. To check if a JWT is expired: decode the payload to find the exp value, convert it to a human-readable date, and compare it against the current UTC time. If exp < now, the token is expired. jslet's JWT Decoder does this automatically — it decodes the exp claim, displays it as a human-readable UTC timestamp, and places a green 'Valid' badge if the token hasn't expired or a red 'Expired' badge if it has. Common related claims to check: 'nbf' (not-before) — the token is not valid before this timestamp, and 'iat' (issued-at) — when the token was created. Always check exp on the client side before making an API call to avoid sending an already-expired token — it saves a round-trip and a 401 error. Note: the server must still verify expiration server-side; client-side JWT decoding is for convenience, not security decisions.

🟢📖 About JWT Tokens