What's inside a JWT
A JSON Web Token is three base64url segments joined by dots: a header naming the signing algorithm, a payload of claims (who the token is for, when it expires), and a signature over the first two. Because the first two parts are only encoded, not encrypted, anyone holding a token can read it; this tool just does that reading for you, locally. Never treat JWT contents as secret, and never put secrets in one.
Why decode locally matters here more than anywhere
The tokens you debug are usually live credentials, a bearer token copied from an Authorization header still grants access until it expires. Pasting one into a web tool with a backend hands your session to a stranger. This decoder is pure client-side JavaScript: open devtools, watch the network tab, decode a token, and observe that no request is made.
The claims that answer real questions
When a request is mysteriously 401ing, the answer is nearly always in three claims: exp (expired token, the tool converts it to ISO time and tells you how long ago), nbf (not valid yet, the classic symptom of clock skew between your auth server and API server; keep NTP healthy), and aud/iss (token issued by or for a different service than the one rejecting it, common when staging and production share an identity provider).
Decoding is not verifying
This tool cannot tell you a token is genuine, anyone can mint a syntactically perfect JWT with any claims they like. Authenticity comes only from verifying the signature against the issuer's key, on the server, with a maintained library. Two rules cover most historical JWT vulnerabilities: reject alg: none outright, and pin the algorithms you accept rather than trusting whatever the header declares.