How a JWT is built
A JSON Web Token (RFC 7519) in its usual signed form (JWS, RFC 7515) consists of three base64url segments separated by dots: header.payload.signature. The header names the signing algorithm (alg, for example HS256 or RS256) and the token type. The payload holds the claims: whom the token is about (sub), who issued it (iss), for whom it is meant (aud) and when it expires (exp).
Example
The token shown when this page loads has the header {"alg":"HS256","typ":"JWT"} and the payload {"sub":"user-42","name":"Jane Doe","iat":1767225600,"exp":1767229200}. iat and exp are NumericDates, seconds since 1970-01-01 00:00 UTC: the token was issued on 2026-01-01 at 00:00 UTC and expired one hour later. Its signature is a placeholder. The decoder reads the token all the same, because decoding does not involve the signature.
Decoding is not verifying
Header and payload are only base64url-encoded, not encrypted. Anyone who holds a token can read them, so a JWT payload must never contain secrets. Whether a token is genuine is decided by its signature, which only the holder of the key can check – or, for RS256 and ES256, anyone with the public key. An application has to verify the signature, the expected algorithm and the exp claim with a JWT library before it trusts any claim.
Five segments?
A token with five segments is an encrypted JWE. Its payload cannot be read without the decryption key, so this tool does not decode it.
To decode a single segment by hand, use the base64 decoder, which accepts the URL-safe alphabet without padding.