JWT Explained: Headers, Payloads, and Safe Debugging

JWT explained in plain language: how header and payload claims work, why signature verification matters, and how to decode tokens locally while debugging auth.

A JSON Web Token (JWT) is a compact way to carry claims between parties. The common form is three Base64URL segments separated by dots: header.payload.signature. The header describes the token type and algorithm; the payload holds claims like `sub`, `exp`, and custom fields; the signature binds them so tampering can be detected when verified with the right key.

Decoding the header and payload is useful during debugging — you can see expiry, audience, and roles without calling the issuer. Verification is a separate step: decoding alone does not prove the token is authentic. Never trust unsigned claims in production authorization logic.

Sensitive data in JWT payloads is visible to anyone who has the token. Prefer opaque identifiers and look up details server-side when claims would leak PII. Short expiries and refresh flows reduce the blast radius of leaked tokens.

When an API returns 401s, paste the token into a local JWT decoder to confirm `exp`, `iss`, and `aud` match what your service expects. Keep real production tokens off public paste sites. EverydayDevTools JWT Decoder runs in the browser for that inspection loop.

Related workflows: encode test tokens carefully for staging only, hash secrets with proper password KDFs (not raw JWT signing keys in repos), and pair decoding with URL/Base64 tools when tokens arrive percent-encoded in redirects.