JWT decode vs verify: reading claims is not trusting them
A JWT is three Base64URL segments: header, payload, signature. Decoding shows the JSON. Verifying proves the signature matches a key you trust. ToolDeck only decodes.
The three parts
Anyone can read header and payload. They are encoded, not encrypted. (JWE is the encrypted form; it is a different token.)
- Header — algorithm and type (
alg,typ). - Payload — claims (
sub,exp,iat, custom fields). - Signature — HMAC or public-key signature over
header.payload.
Why this site will not “verify” in your browser
Verification needs the secret (HMAC) or the issuer’s public key. Pasting production secrets into a web page is a bad habit, even when the page is local.
A green “valid” badge on a random website also teaches the wrong lesson: validity is always relative to a key and an audience you choose in your app.
What to check after decoding
exp— is it still in the future?nbf/iat— is it being used too early?aud/iss— do they match what your app expects?alg— rejectnoneand algorithms you did not plan to accept.
Questions
- Can someone forge a JWT if I only decode?
- They can edit the payload and re-encode it, but a correct verifier will reject the signature. Never trust claims without verify in your server.
- Why is exp a large number?
- It is a Unix timestamp in seconds. The JWT tool shows it as a UTC date.
See also
Related tool: JWT decoder. Runs in your browser; input is not uploaded.