Use this guide to understand what a JWT decoder shows you, which claims are commonly checked in development, and why decoding is not the same as verification.
JWT decoders are useful because auth bugs are usually not about the token looking broken. They are about one field being unexpected: the audience is wrong, the subject is missing, the issued-at time is stale, or the token has already expired.
A decoder lets you inspect the token structure quickly, but it is important to remember that reading a token is not the same as validating it. You can decode an invalid or tampered token just fine if the payload is still parseable.
The three JWT parts
A JWT consists of header, payload, and signature. The header usually tells you the algorithm and token type. The payload contains claims, which are the values your application reads. The signature is used to verify integrity.
When you are debugging, the payload is usually the part you inspect first, but header values such as alg can also matter when tokens are issued by multiple services.
Claims developers check most often
The most frequently checked claims are exp, iat, nbf, sub, iss, and aud. These fields tell you whether the token is still valid in time, who issued it, who it belongs to, and which application is meant to accept it.
If a token works in one environment and fails in another, aud and iss are often the first values worth checking.
- exp: the expiration time, usually stored as a Unix timestamp in seconds.
- iat: when the token was issued.
- sub: the subject, often a user or service identifier.
- aud: the intended audience, such as a client ID or API name.
Decoding is not signature verification
A browser-based decoder is excellent for inspection, but it should not be treated as proof that the token is trustworthy.
To verify authenticity, your application or backend still needs to validate the signature with the correct key and enforce claim checks such as issuer, audience, and expiration.