JWT Decoder
Inspect JWT structure, registered time claims, and security signals locally. Decoding does not verify the signature.
0 characters
Decoder boundary
Decode claims locally without pretending they are verified
The page accepts a three-part compact JWT, Base64URL-decodes the header and payload, parses their JSON, reports signature length, and interprets exp, nbf, and iat when they are numeric dates. It deliberately does not accept a key or claim that the token is authentic.
Security signals shown by the tool
| Observed token detail | What Z Tools reports |
|---|---|
alg=none | Explicit unsigned-token warning |
| Signed algorithm + empty signature | Rejected as malformed |
| HS256 / RS256 / ES256 families | Explains the key type required for real verification |
Numeric exp | UTC time plus expired / time-remaining context |
Numeric nbf | UTC time plus active / not-active-yet context |
Missing numeric exp | Notes that lifetime policy still belongs to the issuer/verifier |
What decoding cannot prove
- Signature validity: a readable header/payload is not evidence that the issuer signed the token.
- Issuer/audience policy: even a cryptographically valid token can be invalid for your application if
iss,aud, scope, tenant, or other claims do not match policy. - Algorithm policy: verification code should pin the algorithm(s) expected by the application instead of trusting the token header blindly.
- Privacy boundary: the decoder algorithm runs in browser JavaScript and does not POST the token to a JWT-processing endpoint. Avoid placing sensitive tokens in shareable URLs or unrelated support messages.
Use a maintained JWT library inside the system that owns the expected key and verification policy. For examples of why decode and verify are different, read JWT Security Pitfalls and RFC 7519.