What a JWT contains
A JSON Web Token is three Base64URL-encoded parts joined by dots: a header, a payload and a signature. The header says how the token was signed. The payload holds the claims: who the token is for, who issued it and when it expires. The signature proves the first two parts weren’t changed.
Anyone can read a JWT’s header and payload; they are encoded, not encrypted. Never put secrets in a JWT payload.
Standard claims
iss(issuer): who created the token, usually your identity provider’s URL.sub(subject): the user or client the token represents.aud(audience): the API the token is meant for. APIs should reject tokens meant for someone else.exp(expiry),iat(issued at),nbf(not before): Unix timestamps in seconds.scopeorscp: the permissions granted, often space-separated.
Debugging 401 errors
When an API rejects a token, check these in order:
- Has it expired? Compare
expwith the current time shown above. - Is
audthe API you’re calling? Tokens issued for one API are often rejected by another. - Does
scopeinclude the permission the endpoint needs? - Is the server clock in sync? A few minutes of clock skew can make a fresh token look not yet valid.
Why this tool doesn’t verify signatures
Verifying a signature needs the signing secret (for HS256) or the issuer’s public key (for RS256 and ES256). Pasting a production secret into any website is a risk, so verification belongs in your backend, using a maintained library such as jose for Node.js or Spring Security’s resource server for Java.