JWT Decoder

A signed JWT (RFC 7519, using the JWS format from RFC 7515) is three Base64URL strings joined by dots:

header.payload.signature

header    {"alg":"HS256","typ":"JWT"}            -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
payload   {"sub":"user_8f3a2c71","exp":4102444800} -> eyJzdWIiOiJ1c2VyXzhmM2EyYzcxIiwiZXhwIjo0MTAyNDQ0ODAwfQ
signature HMAC-SHA256(header + "." + payload, secret), Base64URL-encoded

The header names the signing algorithm (alg) and often a key ID (kid) that tells the verifier which key to use. The payload holds the claims. The signature is computed over the exact first two segments, so changing a single character in either one invalidates it. Since every eyJ you see is just {" in Base64, the header and payload are readable by anyone who holds the token.

A token with five segments is a JWE, an encrypted JWT. Its payload is ciphertext, and no decoder can show it without the recipient's key.

The three time claims are NumericDate values: seconds since 1970-01-01 UTC, not milliseconds. Writing Date.now() instead of Math.floor(Date.now() / 1000) creates a token that expires in the year 55,000. Convert individual values with the epoch converter. Everything else in the payload is a custom claim, such as email, roles or scope.

Because the payload is only encoded, never put passwords, API keys or sensitive personal data in it. Assume that every proxy log, browser extension and support ticket that sees the token can read it.

• HS256 is HMAC with SHA-256. The same shared secret signs and verifies, so every service that can check a token can also mint one. It fits a single backend. RFC 7518 requires a key of at least 256 bits; short passwords can be brute-forced offline from any captured token.
• RS256 is RSA with SHA-256. The issuer signs with a private key and publishes the public key, usually as a JWKS document. Any number of APIs can verify without being able to issue tokens. This is the common default for identity providers.
• ES256 is ECDSA on the P-256 curve. It has the same public-key model as RS256 with much shorter keys and signatures (64 bytes instead of 256 for RSA-2048).

Whatever the algorithm, the server should accept only the algorithms it expects. Letting the token's own alg header pick the algorithm is how alg: none and RS256-to-HS256 confusion attacks work.

• Expired: exp is in the past. Access tokens often live for 5–60 minutes, so a token copied from a log an hour ago is usually dead. Use the refresh flow rather than extending the lifetime.
• Clock skew: a token rejected right after login, with an error such as jwt not active (Node's jsonwebtoken) or The token is not yet valid (iat) (PyJWT), means the API server's clock is behind the issuer's. Fix NTP on the server, and allow a small leeway (30–60 seconds is common) in the validation settings.
• Wrong audience: the token was issued for a different API, often an ID token sent where an access token was expected. Compare aud with the audience your API is configured for.
• Wrong issuer or key: iss differs by a trailing slash or tenant, or the kid is not in the JWKS the API downloaded, which happens after key rotation if the key set is cached too long.

Where to store tokens

There is no universally right answer. An HttpOnly, Secure, SameSite cookie keeps the token away from JavaScript, so XSS cannot read it, but you then need CSRF protection. Memory or localStorage avoids CSRF but exposes the token to any script running on the page. Short lifetimes and refresh token rotation limit the damage in either case. For the same reason this page does not save the token you paste.