What a JWT decoder shows you
A JSON Web Token is three Base64URL-encoded parts separated by dots: a header, a payload and a signature. The header names the signing algorithm, such as HS256 or RS256. The payload carries the claims: who the token is about (sub), who issued it (iss), who it is for (aud), and when it was issued (iat), becomes valid (nbf) and expires (exp).
Decoding is not the same as verifying. Anyone can read a JWT, because the header and payload are only encoded, not encrypted. This inspector shows exactly what the token contains and flags expired tokens, but it does not claim a signature is valid. Signature checks belong on your server, with the real key.
Debugging common token problems
Most "401 Unauthorized" errors with a token come down to a handful of causes: the token has expired, the audience or issuer does not match what the API expects, the clock on one machine is ahead of the other so nbf is still in the future, or the token was copied with a stray "Bearer " prefix or line break. Reading the decoded claims next to their human-readable times usually points to the cause within seconds.
Tokens often contain user IDs, email addresses and roles. The decoder runs in your browser and does not send the token anywhere, which matters when you are inspecting tokens from a production system.
Generating test tokens
Switch to Generate to build a signed token for local development and tests. Choose HS256, HS384 or HS512, enter a shared secret, and set the subject, audience, issuer and lifetime. The token is signed with the Web Crypto API, so you can paste it straight into an Authorization header in the REST Client.
