What this tool does
A JSON Web Token (JWT) is made up of three parts separated by dots: a header describing the signing algorithm, a payload holding the actual data (user identity, permissions, expiration date, and so on), and a signature that guarantees the first two parts haven't been tampered with since they were issued.
This tool decodes the header and payload into readable JSON, and can verify the signature if you provide the matching secret (HS256) or public key (RS256) — all without the token ever leaving your browser.
Decoding isn't the same as authenticating
A JWT's header and payload are just base64url-encoded, not encrypted: anyone can read them, no signing secret required. That trips people up constantly — decoding a token to peek at its contents tells you nothing about whether it's genuine. Only a signature check, run with the correct key, confirms the token was actually issued by the service you expect and hasn't been altered since.
HS256 vs. RS256
HS256 relies on a single shared secret: the same value both signs and verifies, which means anyone who can verify a token can also mint new ones. RS256 uses an asymmetric key pair instead: the private key signs, the public key verifies — so a third-party service can validate tokens without ever gaining the ability to issue them. That's why RS256 is the go-to choice once multiple services need to verify tokens issued by one central authority.
The payload's date fields
Three standard fields show up in most JWTs: iat (issued at, when the token was created), exp (expiration, the point past which the token must be rejected), and nbf (not before, a date before which the token shouldn't be accepted). In the raw payload these are just Unix timestamps — this tool converts them to readable dates automatically and flags whether the token has expired.