Decoding vs verifying a JWT: why a readable token proves nothing

How this is calculated

Every JWS token has three parts: header, payload and signature. Decoding reverses the Base64url encoding of the first two parts and parses the JSON. That's it. No key is involved, which is why a browser extension, a log viewer or this page can show you a token's claims instantly. Verification works on the exact text of the first two parts. The verifier joins them with a dot, runs the algorithm from an allowlist it chose itself (HMAC with SHA-256 for HS256, RSA PKCS #1 v1.5 for RS256, ECDSA for ES256), and compares the result with the signature part. If a single character of the header or payload changes, the check fails. The catch is that the payload is under the sender's control. A forged token can say "role": "admin" just as easily as a real one. Front ends often decode a token to show a user's name or to know when to refresh it, and that's fine, since the server verifies it again on every request. The mistake is a server or an API gateway that decodes and trusts. The JWT Decoder keeps the two apart on purpose: it labels every token Unverified until a real Web Crypto signature check passes for the token and key on screen.

Verdict

Decode freely for debugging and for display. Verify on the server for anything that grants access, and do it with a key you got from the issuer, never one the token points to. Once the signature passes, the work isn't done: check exp and nbf, check that iss and aud match what your service expects, then check the scopes or roles for the action.