A JWT's header and payload are plain Base64url, readable by anyone. Signature verification is the part that matters. Here is the difference, with the common failure modes.
A JSON Web Token is three Base64url strings joined by dots: header, payload and signature. The first two are not encrypted — anyone holding the token can read every claim in it. Never put anything confidential in a JWT payload.
The JWT Decoder splits and pretty-prints those claims locally, so you can inspect a real production token without pasting it into a remote service.
exp — expiry, as a Unix timestamp. An expired token is the single most common cause of a sudden 401.iat and nbf — issued-at and not-before. Clock skew between services makes these fail intermittently, which is the hardest version of this bug to catch.aud and iss — audience and issuer. A valid signature from the wrong issuer is still an invalid token.alg in the header — if it says none, something is very wrong.Decoding tells you what a token claims. Verifying tells you whether to believe it: recomputing the signature over header.payload with the shared secret (HMAC) or the issuer's public key (RSA/ECDSA), then comparing. A decoder alone can never tell you a token is trustworthy — it does not hold the key.
If you need a token for a test fixture, build one with the JWT Signer: set the claims, supply a throwaway secret and copy the HMAC-signed result.
-/_ are converted and = re-added.