ZeroTrace OSINT
JWT Decoder
Parse JWT tokens, verify signatures against pasted keys or fetched JWK Sets, surface alg-confusion warnings.
The JWT decoder takes a JSON Web Token, parses the three parts (header / payload / signature), and surfaces every claim with annotations from a built-in claims glossary. Optionally it verifies the signature against a pasted public key or against a JWK Set fetched from the issuer's .well-known/jwks.json.
What you get
For any JWT:
| Section | What it shows |
|---|---|
| Header | alg, typ, kid, custom header fields |
| Payload (claims) | Every claim with annotations from the standard JWT claims registry |
| Signature | Raw signature bytes, base64url-encoded |
| Token validity window | iat, nbf, exp with freshness chip |
| Standard-claim glossary | iss, sub, aud, jti, iat, exp, nbf annotated automatically |
| Custom claims | Surfaced as-is (no annotation; you interpret them) |
| Signature verification | Optional: verify against pasted public key or fetched JWK Set |
| Algorithm confusion warning | Flag if alg is unusual or asymmetric algorithm with key size that fits a symmetric secret |
Standard-claim glossary
The decoder annotates the canonical claims:
| Claim | Meaning |
|---|---|
iss | Issuer — who created the token |
sub | Subject — who the token is about |
aud | Audience — who the token is for |
exp | Expiry — when the token stops being valid |
nbf | Not before — when the token starts being valid |
iat | Issued at — when the token was created |
jti | Unique token ID — for revocation |
Custom claims (anything not in the standard registry) are surfaced as-is.
Validity window
The decoder evaluates the token against the current time:
iat(issued at) — when the token was created.nbf(not before) — when the token starts being usable.exp(expiry) — when the token stops being valid.
A token currently outside its validity window is flagged.
Signature verification
Two verification modes:
| Mode | When to use |
|---|---|
| Paste public key | You have the issuer's PEM-encoded public key |
| Fetch JWK Set | You have the issuer's URL — the decoder fetches <issuer>/.well-known/jwks.json and finds the matching key by kid |
Verification supports the common JWT algorithm families: HS256/384/512 (HMAC), RS256/384/512 (RSA), ES256/384/512 (ECDSA), PS256/384/512 (RSA-PSS), EdDSA.
A successful verification confirms:
- The token was signed by the holder of the corresponding key.
- The token has not been modified since signing.
A failed verification means one or the other is false. The decoder tells you which.
Signature verification confirms the token was signed by some key — it does not by itself prove the token is "valid." A token signed by an attacker-controlled key passes verification with that attacker's key. Always verify against a key you trust came from the legitimate issuer.
Algorithm confusion warning
A classic JWT vulnerability: a server expects RS256 but accepts HS256 with the public key as the symmetric secret. The decoder flags this when:
- The token's
algis symmetric (HS256/384/512). - The token's key looks like it could be a public key (PEM-shaped).
This is a sanity check, not a verdict — many legitimate setups use symmetric keys. But the warning catches the misconfiguration that the most common JWT bypass exploits.
None-algorithm warning
A token with alg: none is unsigned. The decoder flags this prominently — accepting alg: none is the other classic JWT vulnerability.
Pivots
| Click on... | Pivot to |
|---|---|
iss URL | URL parser, site analysis |
aud URL | URL parser |
| Custom URL claim | URL parser |
| Email-shaped claim | Email analyzer |
Bulk JWT decode
Bulk paste accepts many tokens. Aggregate table shows per-token issuer / subject / expiry / valid-now status — useful for triaging a log file full of tokens.
Sources
- All decoding is local.
- JWK Set fetches go to the URL you provide — the URL is named on the result.