JWT decode vs verify: why decoding is not enough

Decode and verify are different steps. Mixing them up is a common security mistake: readable claims are not proof that a trusted issuer signed the token.

What decode means

Decoding splits the JWT and turns the header and payload from Base64URL into JSON. Anyone with the token can do this. Public JWT decoders (including Jigglify) are decode-only helpers for debugging.

What verify means

Verification checks the signature with a secret (HMAC) or public key (RSA/ECDSA), and usually validates exp, nbf, audience, and issuer. That must happen in a trusted backend - never in untrusted client code alone for access control.

Why public tools should not claim verification

Verification needs your keys. A third-party page that asks for secrets is a risk. A decoder that never claims "valid signature" is the safer default for inspecting tokens during development.

Practical checklist

1. Decode locally to understand claims and expiry while debugging.
2. Verify on the server with allow-listed algorithms and the correct key.
3. Reject expired tokens and unexpected issuers or audiences.
4. Never trust alg alone from an untrusted token.

Inspect a JWT safely - decode only, in your browser, with a clear verify-on-server reminder.
Open the free JWT decoder →

Related: What is a JWT? · How to decode a JWT