If a tool can decode a JWT without a key, decoding cannot be proof that the token is authentic. The header and payload are designed to be readable. Trust begins only when a verifier checks the signature with an expected key/algorithm and validates application claims.
What the Z Tools decoder does
- Splits the three compact JWT segments and Base64URL-decodes the first two locally.
- Parses header/payload JSON when valid.
- Translates
exp,nbf, andiatnumeric dates into readable times and marks expired/not-yet-valid states relative to the client clock. - Shows context warnings for missing
alg,alg=none, and common HS/RS/ES algorithm families. - Does not claim to verify the signature.
Time claims are necessary but not sufficient
exp tells a verifier when the token should stop being accepted; nbf can delay validity; iat records issuance time. A debugger can compare those values with the current clock, but a production verifier also needs a defined clock-skew policy and must decide which claims are mandatory.
Never let untrusted input choose your verification policy
The header’s alg value is data supplied by the token. A secure application should constrain acceptable algorithms in configuration and use a library that enforces key/algorithm compatibility. Historical JWT vulnerabilities often came from treating header choices too flexibly.
Issuer and audience matter
A cryptographically valid signature can still belong to the wrong issuer or service. Applications commonly validate iss, aud, subject/permissions, token type, and other domain claims after signature verification. Z Tools cannot know your application’s trust policy, so it deliberately does not label a decoded payload “valid.”
Do not paste production secrets into shareable URLs
Primary token decoding is local. However, the site’s access logger records requested paths, and some tools support URL state. Treat real bearer tokens as secrets: prefer a fresh page, avoid query-string sharing, and use synthetic tokens for screenshots/support reports.
Primary standards
JWT is specified by RFC 7519; JSON Web Signature is RFC 7515. Application frameworks may impose additional validation profiles.