JWT Decoding Is Not Verification: The Checks That Actually Matter

A JWT decoder can make a token readable, but it cannot tell you whether the token should be trusted.

A JSON Web Token usually has three dot-separated parts: a header, a payload, and a signature. Decoding Base64URL turns the first two parts into readable JSON. That is useful for debugging, but it proves nothing about who created the token or whether it was modified.

What verification must check

A secure verifier should do all of the following:

1. Verify the signature using the issuer's expected key.
2. Enforce an allowed algorithm instead of trusting the token's alg field blindly.
3. Validate exp and reject expired tokens.
4. Validate nbf before accepting a token that is not active yet.
5. Match iss to the expected issuer.
6. Match aud to the service receiving the token.
7. Apply a small, deliberate clock-skew allowance when appropriate.

A token can contain perfectly readable claims and still be forged, expired, or intended for a different API.

A safer debugging habit

Use decoding only to inspect structure and claims. Treat everything you see as untrusted until your application verifies the signature and validates the relevant claims with a maintained JWT library.

This is also why developer tools should avoid showing a vague green "valid" state after decoding. Readable is not the same as verified.

I built the browser-only JWT inspector in DevCrate with that distinction in the interface. Decoding runs locally, and the result explicitly says that the signature has not been verified.

Try the DevCrate JWT inspector

What JWT validation mistake have you seen most often in real projects?